RE: Unable to run excel via cron

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

We are running cron under the specific cygwin login (not cyg_server).

Presumably there is a solution to this problem.  We have 3 Win7 Pro PCs and this works on one of the PCs (unfortunately, not the one where we need it to work) and fails on the other two PCs.

Thanks for the two suggested links.  We will check them out.

Denis

------------------------------------------------------------------------------------

Corinna Vinschen Wrote:

On Jun 17 13:29, Kertz, Denis (D)** CTR ** wrote:
> Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
> 
> We are using 64-bit cygwin and 32-bit Excel (Excel 2007).

The problem is probably related to some of the changes between XP and
W7.  On XP, the desktop runs in session 0, just like the services.  With
UAC since Vista, the desktop runs in session 1, while the services
continue to run in session 0.  Therefore services are not allowed to
connect to the desktop anymore since Vista.  UAC itself, as well as
a feature since Windows 2003 (permissions of LocalSystem) may come into
play here as well.  Are you running cron under the cyg_server account
on W7 (hopefully)?

Two possible solutions come to mind:

- Either there is no solution.  The reason might be that Excel is
  expecting a GUI it can't connect to.

- Or it's about the user token after switching the user context.  I
  assume you're running Excel from cron as some other user account than
  cyg_server.  Please read
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
  and try
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3


Corinna

-- 
Corinna Vinschen


--
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

Re: Unable to run excel via cron

[Larry Hall (Cygwin)]

On 06/17/2015 12:55 PM, Kertz, Denis (D)** CTR ** wrote:
> We are running cron under the specific cygwin login (not cyg_server).
>
> Presumably there is a solution to this problem. We have 3 Win7 Pro PCs
> and  this works on one of the PCs (unfortunately, not the one where we need it to
> work) and fails on the other two PCs.

The behavior here has always been somewhat unpredictable.  Some have luck
getting this to work post-XP, some don't.  Some, like you, sometimes have
luck.  It's not clear why.  But it is clear that MS changed the behavior
in Vista and beyond for security reasons.  They are trying to make this
difficult if not impossible to do.  As Corinna mentioned, getting an
Windows authenticated token for the user running the server may help.
Or not. ;-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

I'm not sure but I think Larry was saying the issue was that Excel by its nature is an interactive program and that was the crux of the problem, even though I was running Excel without any interactive input.  (And Larry wanted to emphasize this wasn't a cygwin problem per se - it was a problem with getting cygwin/cron to function within the windows structure.)

However, sometimes you get lucky even though you don't quite know what you are doing.  Having given up on being able to run Excel from a cron I started investigating running a bash script via the windows task scheduler (http://www.davidjnice.com/cygwin_scheduled_tasks.html).  A colleague of mine had already set up some Excel programs running from the task scheduler and I checked them out and noticed he ran them via a vbscript by creating a shell to run the Excel programs.  A light bulb went off and, guessing that a shell is by definition able to handle an interactive program like Excel, I ran this vbscript from a cron job (run with c:/Windows/System32/wscript.exe):

Dim objShell
Set objShell = Wscript.CreateObject("WScript.Shell")
objShell.Run "C:\cygwin64\home\<login>\TestExcel.xls", 1, true
Set objShell = Nothing

This worked!  The cron ran the TestExcel.xls via WScript.Shell and this .xls saved itself (saveas) as a .htm file.  This demonstrated that an Excel program could be run and it could create a file.  This also worked with the cron set up to run either under cygserver or my cygwin login.

There was one wrinkle here.  The previous script that wouldn't run under Win7 was set up to initiate the Excel program and then terminate it.  This shell approach initiated the Excel program but left the Excel program still running.  I had to add an explicit 'Application.Quit' in my Excel macro to force the termination of Excel, a fairly minor change.

Thanks to all who helped me reach this solution.  Hopefully it may help others with a similar problem.

Denis

-------------------------------------------------------------------------------------------------------------------------
Andy Hall wrote:

I think Denis is saying Excel hangs even if it doesn't require user interaction. 
 I.e.  it runs some macros and exits.   On Win7 Pro, I was able to run the following 
.vbs script via the task scheduler and have it run the  "AddTimeInColumn" macro.
The resulting spreadsheet had the times the task was run column A.

Andy

--
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

RE: Unable to run excel via cron

[Andy Hall]

> On 06/23/2015 09:39 AM, Kertz, Denis (D)** CTR ** wrote:
> > I changed the cron setup to use cygserver as Corinna suggested.  I used
> > cron-config and cygserver-config to setup the cron and cygserver services
> > and passwd -R to establish my password.  Normal cron jobs run under this
> > setup but Excel still hangs as it did before.  I also tried this on the
> > Win7 PC that I thought worked at one time but it behaved the same with
> > Excel hanging.
> >
> > So it looks like Corinna's first case is the situation - there is no
> > solution.  There apparently is something unique about Excel that will not
> > run in this Win7 cron environment.
> 
> It's actually not unique to Excel and it's not peculiar to Cygwin's cron.
> Any program that requires desktop interaction to run would suffer this same
> limitation on Vista and beyond if started from a service.  In the Cygwin
> environment, cron is run as a service and used to start programs, so it's
> the obvious 'culprit' reported here but it's just one of many possible
> vectors that exhibit the unwanted behavior on Windows.  Just FYI.
> 
> --
> Larry
> 
I think Denis is saying Excel hangs even if it doesn't require user interaction. 
 I.e.  it runs some macros and exits.   On Win7 Pro, I was able to run the following 
.vbs script via the task scheduler and have it run the  "AddTimeInColumn" macro.
The resulting spreadsheet had the times the task was run column A.

Andy

Here's the .vbs script:

Dim args, objExcel

Set args = WScript.Arguments
Set objExcel = CreateObject("Excel.Application")

objExcel.Workbooks.Open("C:\cygwin64\home\Andy\ExcelTest\TestExcel.xlsm")
objExcel.Visible = True

objExcel.Run "AddTimeInColumn"

objExcel.ActiveWorkbook.Save
objExcel.ActiveWorkbook.Close(0)
objExcel.Quit

Here's the macro:

Public Sub AddTimeInColumn()

    Dim LastRowInColumn As Long
    
    LastRowInColumn = Cells(Cells.Rows.Count, "A").End(xlUp).Row
    
    'If column is completely blank, need to adjust last row
    If Cells(LastRowInColumn, "A").Value = "" Then LastRowInColumn = 0
    
    'Insert time in next row
    Cells(LastRowInColumn + 1, "A").Value = Time()

End Sub




--
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

Re: Unable to run excel via cron

[Larry Hall (Cygwin)]

On 06/23/2015 09:39 AM, Kertz, Denis (D)** CTR ** wrote:
> I changed the cron setup to use cygserver as Corinna suggested.  I used
> cron-config and cygserver-config to setup the cron and cygserver services
> and passwd -R to establish my password.  Normal cron jobs run under this
> setup but Excel still hangs as it did before.  I also tried this on the
> Win7 PC that I thought worked at one time but it behaved the same with
> Excel hanging.
>
> So it looks like Corinna's first case is the situation - there is no
> solution.  There apparently is something unique about Excel that will not
> run in this Win7 cron environment.

It's actually not unique to Excel and it's not peculiar to Cygwin's cron.
Any program that requires desktop interaction to run would suffer this same
limitation on Vista and beyond if started from a service.  In the Cygwin
environment, cron is run as a service and used to start programs, so it's
the obvious 'culprit' reported here but it's just one of many possible
vectors that exhibit the unwanted behavior on Windows.  Just FYI.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

I changed the cron setup to use cygserver as Corinna suggested.  I used cron-config and cygserver-config to setup the cron and cygserver services and passwd -R to establish my password.  Normal cron jobs run under this setup but Excel still hangs as it did before.  I also tried this on the Win7 PC that I thought worked at one time but it behaved the same with Excel hanging.

So it looks like Corinna's first case is the situation - there is no solution.  There apparently is something unique about Excel that will not run in this Win7 cron environment.

Denis

---------------------------------------------------------------------------------------------------

Corinna Write:

Two possible solutions come to mind:

- Either there is no solution.  The reason might be that Excel is
  expecting a GUI it can't connect to.

- Or it's about the user token after switching the user context.  I
  assume you're running Excel from cron as some other user account than
  cyg_server.  Please read
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview  and try
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3


Corinna

--
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

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

Well, not so lucky anymore.  Last night I re-ran my Excel test on the Win7 PC that worked previously and now it doesn't work.  So I guess some Win7 patch must have come along and "fixed" something.

Denis

Larry Hall wrote:

On 06/17/2015 12:55 PM, Kertz, Denis (D)** CTR ** wrote:
> We are running cron under the specific cygwin login (not cyg_server).

> Presumably there is a solution to this problem. We have 3 Win7 Pro PCs
> and  this works on one of the PCs (unfortunately, not the one where we need it to
> work) and fails on the other two PCs.

The behavior here has always been somewhat unpredictable.  Some have luck
getting this to work post-XP, some don't.  Some, like you, sometimes have
luck.  It's not clear why.  But it is clear that MS changed the behavior
in Vista and beyond for security reasons.  They are trying to make this
difficult if not impossible to do.  As Corinna mentioned, getting an
Windows authenticated token for the user running the server may help.
Or not. ;-)

--
Larry


--
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

RE: Unable to run excel via cron

[Andy Hall]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Kiehl, Horst
> Sent: Wednesday, June 17, 2015 8:10 AM
> To: Kertz, Denis (D)** CTR **; cygwin@cygwin.com
> Subject: RE: Unable to run excel via cron
> 
> (Trying to remove TOFU to make the conversation appear chronological again and with correct attributions.)
> 
> Kertz, Denis (D)** CTR ** <d.kertz at alcatel-lucent dot com> wrote:
> > > > We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP
> machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
> > > >
> > > > Here's the script to run a simple test excel program:
> > > >
> > > > [...]
> 
> Bryan Berns wrote:
> > > What bitness of Excel and Cygwin are you running?
> > >
> > > CreateObject("Excel.application") will attempt to create a 32-bit
> > > instance of Excel when launched through the 32-bit version of
> > > wscript.exe or a 64-bit instance of Excel when launched through the
> > > 64-bit version of Excel.  Which bitness of WScript.exe ends up being
> > > run will depend on the bitness of the parent program (which may be
> > > different in a command prompt vice Cygwin).  Try changing it to run
> > > Wscript.exe in SysWow64 instead of System32 (which is subject to
> > > automatic redirection) and see if changes the behavior.  If you're not
> > > running a 64-bit OS, then just ignore everything I said.
> 
> Kertz, Denis (D)** CTR ** wrote:
> 
> > Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
> >
> > We are using 64-bit cygwin and 32-bit Excel (Excel 2007).
> 
> Although the aspect Corinna wrote about may be the culprit already,
> just in case:
> 
> It appears that you, Denis, were misunderstanding Bryan. The consequence
> of what he tried to point out might be that you, using 64-bit Cygwin and
> 32-bit Excel, would have to explicitly use the 32-bit wscript.exe
> instead of the 64-bit wscript.exe, to make sure that wscript.exe
> (32-bit) will start Excel (32-bit) successfully. In other words, you
> might have to use $windir/SysWOW64/wscript.exe (i.e.
> %windir%\SysWOW64\wscript.exe) from your 64-bit Cygwin process.
> 
> (The reason for the seemingly backwards 32-bitness and 64-bitness of
> executables in SysWOW64 and system32, respectively, if viewed from a
> 64-bit process, is to make code with hardcoded "system32", whether
> compiled or interpreted, continue to work in a 64-bit context as well as
> in a 32-bit context.)
> 
> Horst
> 
Years ago,  I had a similar problem on Windows Server 2003.  I needed to run a component of Visual Studio in a
Cygwin-based nightly build system.   It would not run unless Visual Studio was running prior to the builds starting.   I
solved it by first bringing up Visual Studio this way.

VISUAL_STUDIO="Microsoft Visual Studio 8"

ps -W | grep -q "$VISUAL_STUDIO" || \
	cygstart --showminnoactive \
	"/cygdrive/c/Program Files/$VISUAL_STUDIO/Common7/IDE/devenv.exe" /edit

So my question is, does having the Excel UI visible prior to running the cron job help?  

The other difference is I used the Windows Task Scheduler instead of cron to kick off the nightly build.   The .bat file
(still running, but obviously obsolete)  is

======
	@echo off

	C:
	chdir C:\cygwin\bin

	rem set CYGWIN=ntsec
	set CYGWIN=binmode,nodosfilewarning

	bash --login -i "/home/build/bin/nightly_bootstrap.sh"
======

This seemed to side-step any problems resulting from the differences in permission handling between Cygwin and Windows.


--
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

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

Yes, I was confused, by the system32, but I still managed to do what was suggested.  Previously I was running:

	c:/Windows/System32/wscript.exe 'c:\cygwin64\home\Upar3\tst.vbs'

Then as suggested I ran:

	c:/Windows/SysWow64/wscript.exe 'c:\cygwin64\home\Upar3\tst.vbs'

Both versions of wscript.exe resulted in the same behavior - excel hung.

Denis

------------------------------------------------------------------------------------------------------------

Kiehl, Horst wrote:

Yes, I was confused, by the system32 but I still managed to do what was suggested.

(Trying to remove TOFU to make the conversation appear chronological again and with correct attributions.)

Kertz, Denis (D)** CTR ** <d.kertz at alcatel-lucent dot com> wrote:
> > > We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
> > >
> > > Here's the script to run a simple test excel program:
> > >
> > > [...]

Bryan Berns wrote:
> > What bitness of Excel and Cygwin are you running?
> >
> > CreateObject("Excel.application") will attempt to create a 32-bit
> > instance of Excel when launched through the 32-bit version of
> > wscript.exe or a 64-bit instance of Excel when launched through the
> > 64-bit version of Excel.  Which bitness of WScript.exe ends up being
> > run will depend on the bitness of the parent program (which may be
> > different in a command prompt vice Cygwin).  Try changing it to run
> > Wscript.exe in SysWow64 instead of System32 (which is subject to
> > automatic redirection) and see if changes the behavior.  If you're not
> > running a 64-bit OS, then just ignore everything I said.

Kertz, Denis (D)** CTR ** wrote:

> Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
>
> We are using 64-bit cygwin and 32-bit Excel (Excel 2007).

Although the aspect Corinna wrote about may be the culprit already,
just in case:

It appears that you, Denis, were misunderstanding Bryan. The consequence
of what he tried to point out might be that you, using 64-bit Cygwin and
32-bit Excel, would have to explicitly use the 32-bit wscript.exe
instead of the 64-bit wscript.exe, to make sure that wscript.exe
(32-bit) will start Excel (32-bit) successfully. In other words, you
might have to use $windir/SysWOW64/wscript.exe (i.e.
%windir%\SysWOW64\wscript.exe) from your 64-bit Cygwin process.

(The reason for the seemingly backwards 32-bitness and 64-bitness of
executables in SysWOW64 and system32, respectively, if viewed from a
64-bit process, is to make code with hardcoded "system32", whether
compiled or interpreted, continue to work in a 64-bit context as well as
in a 32-bit context.)

Horst

--
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

RE: Unable to run excel via cron

[Kiehl, Horst]

(Trying to remove TOFU to make the conversation appear chronological again and with correct attributions.)

Kertz, Denis (D)** CTR ** <d.kertz at alcatel-lucent dot com> wrote:
> > > We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
> > >
> > > Here's the script to run a simple test excel program:
> > >
> > > [...]

Bryan Berns wrote:
> > What bitness of Excel and Cygwin are you running?
> >
> > CreateObject("Excel.application") will attempt to create a 32-bit
> > instance of Excel when launched through the 32-bit version of
> > wscript.exe or a 64-bit instance of Excel when launched through the
> > 64-bit version of Excel.  Which bitness of WScript.exe ends up being
> > run will depend on the bitness of the parent program (which may be
> > different in a command prompt vice Cygwin).  Try changing it to run
> > Wscript.exe in SysWow64 instead of System32 (which is subject to
> > automatic redirection) and see if changes the behavior.  If you're not
> > running a 64-bit OS, then just ignore everything I said.

Kertz, Denis (D)** CTR ** wrote:

> Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
>
> We are using 64-bit cygwin and 32-bit Excel (Excel 2007).

Although the aspect Corinna wrote about may be the culprit already,
just in case:

It appears that you, Denis, were misunderstanding Bryan. The consequence
of what he tried to point out might be that you, using 64-bit Cygwin and
32-bit Excel, would have to explicitly use the 32-bit wscript.exe
instead of the 64-bit wscript.exe, to make sure that wscript.exe
(32-bit) will start Excel (32-bit) successfully. In other words, you
might have to use $windir/SysWOW64/wscript.exe (i.e.
%windir%\SysWOW64\wscript.exe) from your 64-bit Cygwin process.

(The reason for the seemingly backwards 32-bitness and 64-bitness of
executables in SysWOW64 and system32, respectively, if viewed from a
64-bit process, is to make code with hardcoded "system32", whether
compiled or interpreted, continue to work in a 64-bit context as well as
in a 32-bit context.)

Horst


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------


--
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

Re: Unable to run excel via cron

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

On Jun 17 13:29, Kertz, Denis (D)** CTR ** wrote:
> Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.
> 
> We are using 64-bit cygwin and 32-bit Excel (Excel 2007).

The problem is probably related to some of the changes between XP and
W7.  On XP, the desktop runs in session 0, just like the services.  With
UAC since Vista, the desktop runs in session 1, while the services
continue to run in session 0.  Therefore services are not allowed to
connect to the desktop anymore since Vista.  UAC itself, as well as
a feature since Windows 2003 (permissions of LocalSystem) may come into
play here as well.  Are you running cron under the cyg_server account
on W7 (hopefully)?

Two possible solutions come to mind:

- Either there is no solution.  The reason might be that Excel is
  expecting a GUI it can't connect to.

- Or it's about the user token after switching the user context.  I
  assume you're running Excel from cron as some other user account than
  cyg_server.  Please read
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
  and try
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

Unfortunately, using the 64-bit wscript.exe didn't change anything - same behavior as before with excel hanging.

We are using 64-bit cygwin and 32-bit Excel (Excel 2007).

Denis

On Tue, Jun 16, 2015 at 9:27 AM, Kertz, Denis (D)** CTR **
<d.kertz@alcatel-lucent.com> wrote:
> We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
>
> Here's the script to run a simple test excel program:
>
> Dim xlApp
> Dim xlWb
> Set xlApp = CreateObject("Excel.application")
> xlApp.Visible = True
> Set xlWb = xlApp.workbooks.Open("c:\Shared\Prospect\Bin\TestExcel.xls")
> xlApp.Quit
> Set xlWb = Nothing
> Set xlApp = Nothing
>

What bitness of Excel and Cygwin are you running?

CreateObject("Excel.application") will attempt to create a 32-bit
instance of Excel when launched through the 32-bit version of
wscript.exe or a 64-bit instance of Excel when launched through the
64-bit version of Excel.  Which bitness of WScript.exe ends up being
run will depend on the bitness of the parent program (which may be
different in a command prompt vice Cygwin).  Try changing it to run
Wscript.exe in SysWow64 instead of System32 (which is subject to
automatic redirection) and see if changes the behavior.  If you're not
running a 64-bit OS, then just ignore everything I said.

--
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

Re: Unable to run excel via cron

[Bryan Berns]

On Tue, Jun 16, 2015 at 9:27 AM, Kertz, Denis (D)** CTR **
<d.kertz@alcatel-lucent.com> wrote:
> We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem.
>
> Here's the script to run a simple test excel program:
>
> Dim xlApp
> Dim xlWb
> Set xlApp = CreateObject("Excel.application")
> xlApp.Visible = True
> Set xlWb = xlApp.workbooks.Open("c:\Shared\Prospect\Bin\TestExcel.xls")
> xlApp.Quit
> Set xlWb = Nothing
> Set xlApp = Nothing
>

What bitness of Excel and Cygwin are you running?

CreateObject("Excel.application") will attempt to create a 32-bit
instance of Excel when launched through the 32-bit version of
wscript.exe or a 64-bit instance of Excel when launched through the
64-bit version of Excel.  Which bitness of WScript.exe ends up being
run will depend on the bitness of the parent program (which may be
different in a command prompt vice Cygwin).  Try changing it to run
Wscript.exe in SysWow64 instead of System32 (which is subject to
automatic redirection) and see if changes the behavior.  If you're not
running a 64-bit OS, then just ignore everything I said.

--
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

Unable to run excel via cron

[Kertz, Denis (D)** CTR **]

We need to run some Excel programs via cron and are using vbscript to do this.  We have this running on a WinXP machine but are having trouble running on a Win7 machine, but we don't think it is a Win7 problem. 

Here's the script to run a simple test excel program: 

Dim xlApp 
Dim xlWb 
Set xlApp = CreateObject("Excel.application") 
xlApp.Visible = True 
Set xlWb = xlApp.workbooks.Open("c:\Shared\Prospect\Bin\TestExcel.xls") 
xlApp.Quit 
Set xlWb = Nothing 
Set xlApp = Nothing 

Here's how we run this test script from a terminal command prompt: 

c:/Windows/System32/wscript.exe 'c:\cygwin64\home\<cygwinLogin>\tst.vbs' 

This runs fine from a command line prompt but hangs when run as a cron job.  We have trapped the error message we get when the workbooks.Open is executed and get this: 

Microsoft Office Excel cannot access the file 'c:\Shared\Prospect\Bin\TestExcel.xls'. There are several possible reasons: 

▒ The file name or path does not exist. 
▒ The file is being used by another program. 
▒ The workbook you are trying to save has the same name as a currently open workbook. 

We don't believe any of these possible reasons apply.  In particular, since it looked like this could be a permission issue, we changed the vbscript to simply copy the TestExcel.xls file and that works fine:

dim filesys
set filesys=CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("c:\Shared\Prospect\Bin\TestExcel.xls") Then
        filesys.CopyFile "c:\Shared\Prospect\Bin\TestExcel.xls", "c:\cygwin64\home\<cygwinLogin>\"
Else
        WScript.Echo "file does not exist"
End If

This hanging also happens if we create a new spreadsheet and try to save it (and this works fine from a command line prompt).  So we can run excel programs from a cron job as long as we don't open an excel program or save a spreadsheet, which means it is useless. 

We also have a couple of other Win7 PCs.  This problem happens on 2 of the 3 Win7 PCs but works on one of the Win7 PCs.  All 3 PCs are running Excel 2007 SP3.  Two of these 3 PCs have the exact same version of Excel 2007 and one works and the other doesn't.

Anybody have any idea what could be going on here?  We only have this cron job problem when running an excel program via vbscript.  We haven't had any cron job problems with other non-excel scripts. 

Denis

--
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