Hi David, hi Taco, On Fr, 08 Feb 2008, David Kastrup wrote:

Isn't that obvious? A pseudo command line is created and called, and Perl splits it at the first space, disregarding the quoting.

No it is not. AFAIS from the source code there is no shell involved here, that is what did surprise me. But I may be wrong, there are so many definitions around in loslibsomething.c that I was lost.

Since the correct interpreter actually gets called, it would seem like

I am not sure, why please does perl get its own path as argument? That cannot be explained with the space splitting AFAIS.

the culprit here would be your Perl interpreter or its runtime libraries/environment.

Hmm, that perl works with spaces in names files, we have tested it. Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- TULSA (n.) A slurp of beer which has accidentally gone down your shirt collar. --- Douglas Adams, The Meaning of Liff

On Fr, 08 Feb 2008, Taco Hoekwater wrote:

perl.exe is called directly, by the spawnvpe() call. Apparently, it gets this in its argv:

argv[0] = C:/tl argv[1] = test/2008/tlpkg/tlperl/bin/perl.exe argv[2] = c:/tl argv[3] = test/2008/texmf/scripts/texlive/generate-updmap.pl

Uggg. Grmm, ahhh. How does spawnvpe come to the conclusion to call perl AND put all that into the cmdline?

And then it will attempt to load a perl script by the name it finds in argv[1]. To me, that sounds like a runtime library issue (but it could be 'my' msvcrt, it is not necessarily perl's).

Can you send me AGAIN YOUR!! luatex, I was doing this with Akiras! (And deleted yours already ;-) Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- QUENBY (n.) A stubborn spot on a window which you spend twenty minutes trying to clean off before discovering it's on the other side of the glass. --- Douglas Adams, The Meaning of Liff

On Fr, 08 Feb 2008, Taco Hoekwater wrote:

...

Uggg. Grmm, ahhh. How does spawnvpe come to the conclusion to call perl AND put all that into the cmdline?

No idea. I am crystal-balling here.

Hmmm...

...

Can you send me AGAIN YOUR!! luatex, I was doing this with Akiras! (And deleted yours already ;-)

Sent in separate mail.

Same same, without quotes errors out, with quotes does nothing. Enough for today... Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- As he came into the light they could see his black and gold uniform on which the buttons were so highly polished that they shone with an intensity that would have made an approaching motorist flash his lights in annoyance. --- Douglas Adams, The Hitchhikers Guide to the Galaxy

David Kastrup wrote:

Norbert Preining writes:

...

Hi Taco,

I have again a strange thing happening:

for i,v in pairs(command) do print("DEBUG: ",i,v) end ret = os.spawn(command)

gives me: DEBUG: 1 C:/tl test/2008/tlpkg/tlperl/bin/perl.exe DEBUG: 2 c:/tl test/2008/texmf/scripts/texlive/generate-updmap.pl Can't open perl script "test/2008/tlpkg/tlperl/bin/perl.exe": No such file or directory

Do you have any idea where this is coming from? It seems perl is telling me something about opening itself??? I am a bit surprised about that.

Do you have any suggestion? Thanks!

Isn't that obvious? A pseudo command line is created and called, and Perl splits it at the first space, disregarding the quoting.

That's why I thought. You can try adding extra quote characters around all arguments with spaces in them, has says that has a tendency to help.

Norbert Preining wrote:

Hi Taco,

On Fr, 08 Feb 2008, Taco Hoekwater wrote:

...

That's why I thought. You can try adding extra quote characters around all arguments with spaces in them, has says that has a tendency to help.

I added quotes around the args, now the debug statment gives me: DEBUG: 1 "c:/tl test/...." DEBUG: 2 "c:/tl test/...." and there is NO error, but also nothing happens. Normally the called perl scripts issues something, and needs some time for loading, but this here does nothing, it looks like nothing is spawned.

If that is indeed the problem, I can allow an explicit [0] entry in the table to use to spawn the actual executable. This may even be useful in some other scenarios.

Strange enough it looks like this only happens on windows. I created a

I am not very surprised. Windows shell handling has always seemed to me like a kludge on a klugde on a kludge on top of MSDOS 5.0.

directory "a b", did put a sh there, and a script bla.sh doing a echo, and a bla.lua that does os.spawn on the full path, ie somehting like os.spawn("/home/norbert/a b/sh","/home/norbert/a b/bla.sh") (ok that two arguments are put into a table before sending it to spawn)

You can actually shortcut that os.spawn{"/home/norbert/a b/sh","/home/norbert/a b/bla.sh"} is valid lua Best wishes, Taco

David Kastrup writes:

Taco Hoekwater writes:

...

I am not very surprised. Windows shell handling has always seemed to me like a kludge on a klugde on a kludge on top of MSDOS 5.0.

That makes it sound like MSDOS 5.0 would not be a kludge on top of MSDOS 1.0 on top of CP/M (where the surprisingly long-lived 128 character command line originates).

Turtles all the way down...

Or rather turds... -- David Kastrup