On Sun, 2013-04-28 at 22:41 +0300, Eli Zaretskii wrote: > > I think the implementation you have is not quite right. I think the > > parsing of the @-+ stuff is common across all platforms if we have a > > shell, so you don't need the "else /* non-posix shell */". > > I do need a separate code, because it doesn't just remove the @-+ > stuff, it also removes escaped newlines, so that this: > > foo && \ > bar && \ > baz > > is transformed into a single line > > foo && bar && baz > > That's because stock Windows shells don't know about escaped > newlines. I also remove leading whitespace from each logical line, > while at that, because I don't want to rely on Windows shells too much > (some of their internal commands are quite weird).
Ah, OK. I feel like we probably do this parsing more than once. The entirety of job.c needs a good cleaning. But that's for another day. > > Also, I'm not sure about adding things like @echo off to the batch > > file. That assumes that we'll always be using command.com to run > > the batch file, but what if the user specified C:/perl/bin/perl.exe > > or something as their SHELL? > > This is not supported yet; if the user tries that, @echo off will be > the least of their problems ;-) Oh, OK. Sounds fine. I guess I thought you were writing a batch file, then invoking the shell with the batch file name as the command to run. E.g., "command.com <batchfile>" vs. "perl <batchfile>" etc. I am naive but it seems like that should work OK even in Windows :-). I guess there are some tricky bits if you sometimes use the command line and sometimes a batch file (different shell options might be needed for example). _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make