> > The pretest has not started yet and it makes sense to fix all reported bugs > > anyway. > > I did not say I had anything against it.
You asked if it was safe to fix this in Emacs CVS now. > > I don't use Tumme so it would be good if you can test my changes. > > I will. > > > > I am a bit skeptical about > > > the "-c" switch. > > > > What problem can you see? If you see a better fix then you should > > install it. > > The problem with it is that it might now work in all shells. For > example, on Windows, cmd.exe (the default "shell") uses /c, not -c. I > don't know how other shells handle this. I see now. I've fixed this as you suggested with shell-command-switch. > > AFAIK shell-command is is for interactive use: hence the message in > > minibuffer. > > I see now that it is an interactive function, but it accepts optional > extra parameters which suggests that one can use it non-interactively > too, right? Sorry if I misunderstand the purpose and intent of > interactive functions. An interactive function can be used non-interactively but AFAICS the optional extra parameters for shell-command control the output/error of the command, not the minibuffer message. Call-process is more low level and does (I think) what is needed. Why not use it? > By the way, I checked the source and found this, which proves my point: > > (call-process shell-file-name nil t nil shell-command-switch command) > > Please use the same technique, using `shell-command-switch'. > > /Mathias -- Nick http://www.inet.net.nz/~nickrob _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
