I'm seeing this phenomenon I don't quite understand when using a shell call from within a gretl script (with "!"). Without going into the details of what is actually called, the pattern of the following line works alright, with string substitution: ! "C:\mypath\some.exe" C:\morepath\input.csv > C\morepath\output.txt Notice that the exe path is already enclosed in quotes, although it's not really needed; it also works without them in this setup without embedded spaces. The following variants also work: ! C:\mypath\some.exe C:\morepath\input.csv > C\morepath\output.txt ! C:\mypath\some.exe "C:\morepath\input.csv" > "C\morepath\output.txt" However, when I enclose everything in quotes (to be more portable, in case the user name does contain a space) then it fails, i.e. the expected output files are not created! Like this: ! "C:\mypath\some.exe" "C:\morepath\input.csv" > "C\morepath\output.txt" I find this really puzzling - is something going wrong on the way from gretl to the Windows shell, or am I simply missing something?

Am 22.06.2021 um 23:55 schrieb Allin Cottrell: > On Tue, 22 Jun 2021, Sven Schreiber wrote: >> However, when I enclose everything in quotes (to be more portable, in >> case the user name does contain a space) then it fails, i.e. the >> expected output files are not created! Like this: >> >> ! "C:\mypath\some.exe" "C:\morepath\input.csv" > "C\morepath\output.txt" [note that some colons were "eaten" here along the way back-and-forth on the mailing list, the line above is not what I had posted, it's always C-colon-backslash...] >> >> I find this really puzzling - is something going wrong on the way from >> gretl to the Windows shell, or am I simply missing something? > > It might be helpful to know what you're actually trying to do here, in > particular what the "some.exe" is. Fair enough, but instead let me give you a more complete self-contained example: ! "c:\Programme\LyX 2.3\Python\python.exe" c:\users\public\uhu.py > c:\users\public\testout\haha.txt The file uhu.py just contains the statement print(5), and the testout directory exists alright. This call from a gretl script works OK as written above, where only the path to python.exe is quoted. As described before, it fails if I enclose the other paths in quotes. (But both work directly in Windows's cmd prompt.)

Now I see that this sort of thing does not work on Windows. My test example was a trivial program, printarg.exe, which prints out its first argument. My "shell" line in gretl read thus: ! "c:\users\cottrell\printarg.exe" "foo" > "c:\users\cottrell\print.out" Gretl takes this input and turns it into the following request to the operating system (with trailing backslash indicating line continuation):

C:\WINDOWS\system32\cmd.exe /c "c:\users\cottrell\printarg.exe" \ "foo" > "c:\users\cottrell\print.out" which looks OK to me. But Windows comes back with: <windows> C:\WINDOWS\system32\cmd.exe /c "c:\users\cottrell\printarg.exe" \ "foo" 1>"c:\users\cottrell\print.out" 'c:\users\cottrell\printarg.exe" "foo' is not recognized as an internal or external command, operable program or batch file. </windows>

That is, the first two double-quoted elements of the command line have been run together by the OS in a way that's not easy to understand. If you'd like to contribute to getting this working on Windows, please research the required cmd.exe syntax and let me know what we need to do.

Am 24.06.2021 um 02:38 schrieb Allin Cottrell: > > <windows> > C:\WINDOWS\system32\cmd.exe /c "c:\users\cottrell\printarg.exe" \ > "foo" 1>"c:\users\cottrell\print.out" > 'c:\users\cottrell\printarg.exe" "foo' is not recognized as an internal > or external command, operable program or batch file. > </windows>

Am 24.06.2021 um 21:09 schrieb Allin Cottrell: > On Thu, 24 Jun 2021, Sven Schreiber wrote: > >> Am 24.06.2021 um 02:38 schrieb Allin Cottrell: >>> >>> <windows> >>> C:\WINDOWS\system32\cmd.exe /c "c:\users\cottrell\printarg.exe" \ >>> "foo" 1>"c:\users\cottrell\print.out" >>> 'c:\users\cottrell\printarg.exe" "foo' is not recognized as an internal >>> or external command, operable program or batch file. >>> </windows> > > I found a discussion of this on stackoverflow. The weird and wonderful > way of getting this to work is to pass the /s flag to cmd.exe and wrap > the entire command line in an additional pair of quotes: > > cmd.exe /s /c ""some.exe" "some arg" > "some out"" > > That's now in git. Aha?! Will test this on Windows as soon as it's propagated into the snapshots.

On Sat, 26 Jun 2021, Sven Schreiber wrote: > Am 25.06.2021 um 13:51 schrieb Sven Schreiber: >> Am 24.06.2021 um 21:09 schrieb Allin Cottrell: >>> >>> cmd.exe /s /c ""some.exe" "some arg" > "some out"" >>> >>> That's now in git. >> >> Aha?! Will test this on Windows as soon as it's propagated into the >> snapshots. > > Initial testing didn't show any change (= still fails), but I have no > way to tell whether the fix above is already in the snapshot (dated June > 25th), although the time stamps would seem to suggest it. Just to be sure I've put up a new snapshot (regular, not gtk3) today, and tested it on Windows 10.