Greetings, Kertz, Denis (D)** CTR **! >>> What I mean by runs fine is that when I type this command at a bash prompt: >>> run.excel 'c:\Shared\Bin\Create_Daily_Scorecard.xls' >>> it runs to completion and creates a new .xls as its output. When I run >>> this run.excel script from a cron job it hangs. >> >> Hangs as in - do not create new file?
> Hangs as in never finishes and I don't know what, if anything, it has done. > But that suggests some tests for me to run that I should have thought of. > First, create a test .xls that does nothing and see if that runs to > completion. If it does, then create a test .xls that simply creates a file > to test whether it actually creates the file. :) >>> I'm not trying to run Excel interactively from a cron job. One of the >>> limitations with using Excel from a cron job is Excel has to run error free. >>> If Excel does run into some error it will typically generate an error >>> message and wait for a user response. Since Excel is running invisibly from >>> a cron job, there is no user to give a response and Excel just sits there >>> waiting for a response that will never come. >> >> Try starting cron in terminal session and see if anything comes up. > Can you tell me how to do this? When I run the ps command in a terminal > session, I see this: > $ ps > PID PPID PGID WINPID TTY UID STIME COMMAND > 5780 5568 5780 3408 pty0 1000 Nov 5 /usr/bin/bash > 5568 1 5568 5568 ? 1000 Nov 5 /usr/bin/mintty > 3716 5780 3716 1016 pty0 1000 18:58:16 /usr/bin/ps > 1820 1 1820 1820 ? 1000 Nov 5 /usr/bin/cygrunsrv > 1856 1820 1856 1892 ? 1000 Nov 5 /usr/sbin/cron > Do I have to kill the cygrunsrv and cron processes and then ?? Stop (don't kill! Everyone, who use -KILL, must be -KILL'ed) the cron service, then start cron in terminal, using `runas /user:... ...'. So it would run under proper user, and see if anything come up, when it execute your excel job. >>> Why "of course"? Shouldn't I be able to kill my own processes? >> >> It's not "your own" process, it's "cron job" started with your credentials. >> >>> I can certainly do that under WinXP. >> >> Again, only if you logged in as admin. >> This is not the case in Vista+ by default. > Okay, I think what you are telling me is that the login I'm using on "my" > WinXP PC (which I inherited) must be an administrator login By default, the first user account created after system installation (rid:1000), have admin rights. In any system, starting from Win2000. However, WinXP has no concept of privilege escalation, and if you've had admin rights, you were always working with them enabled. > and the login > I'm using on the Win7 PC is not an administrator login (it isn't). That > sounds plausible (I know a lot more about UNIX than I do about Windows). Then just think as if you've been running as root in WinXP, but now, you're running as user with access to sudo facility under Win7. This is not entirely correct, but close enough to give you an idea. > So > the differences I'm seeing between WinXP and Win7 is due to using/not using > an administrator login, not due to whether it is WinXP or Win7. The difference is inherently architectural, and not directly related to using or not using admin account. I think we best keep discussion strictly relevant to your present issue. If you want any more details on Win7 security "improvements", google "UAC description". -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <01:14> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple