On Jan 6, 2008 9:09 AM, Bram Moolenaar wrote: > We haven't been using printf so far, thus this needs to be tested to > find any system where it doesn't work. The opengroup isn't always > right (I don't think they cover Cygwin).
The cygwin developers regularly reference opengroup man pages on the cygwin mailing lists; so it's a safe bet that if their printf doesn't adhere to opengroup's requirements they would consider it a bug and fix it (and their coreutils maintainer is quite responsive and gets out bugfixes quickly.) That being said, I don't have access to a cygwin machine until I'm at work tomorrow, so I'll test then if there isn't a response that it does or doesn't work sooner. > "echo" is a builtin, "printf" is a program. I think this means it will > be a bit slower, right? Not sure if this matters. IIUC, the biggest difference it makes is whether or not execution will require a fork. On most systems, the speed difference would be negligible, but on cygwin systems where fork needs to be emulated (and is very slow as a result), it might be better to not use the preceding "env"; using the builtin if available and falling back to the binary if not. Also, perhaps I missed it, but in a quick reading of the standards I couldn't find any requirement that 'echo' be builtin... > Also, since printf is a program, isn't there a risk that with some > weird arguments something strange may go wrong? A quick test says no: printf "%s\n" --version> correctly prints "--version", with gnu printf, bash printf, and zsh printf, meaning that even those that recognize arguments (gnu printf normally recognizes --version) know to ignore them after the format specification. The only problem I can possibly see is exceding the maximum length of an argument list, which I don't think will be able to happen if we only printf one file per printf call; using a for-loop as suggested above. > Why do you put "env" before "printf"? So, there ought to be no problems with for i in *; do printf "%s\0" $i done for bourne-like shells (tested with bash, ash, dash, and busybox's sh) but clearly that loop won't work for [t]csh... can we assume that /bin/sh always points us to a bourne-compatible shell? Or, alternately, can we check if $SHELL is known not to be bourne-compatible and exec something different? If so, I see no problem with this approach, since "printf" seems to be quite a good deal more rigidly specified than "echo", and it wouldn't hurt our ability to use our shell's extended globs; a zsh loop of: for i in **/*(.-); do printf "%s\0" $i done should continue to work just as well, if not better, than: echo **/*(.-) ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
