Quote:
Only a Microsoft person would create a file with a space in he file name.
I think that is the wrong attitude: as long as something is *legal* it should be covered by a script using it - or at least be clearly stated as limitation. This attitude of "nobody would in his right mind would ever ..." is what accounts for about 100% of all the injection-type problems with web interfaces. The programmers of said interfacess simply didn't believe "anybody in his right mind" would ever enter SQL-code instead of data somewhere.
Quote:
Originally Posted by
alister
That's actually bad advice in general (there is absolutely no need to avoid using a for loop because the list may be very very long), and it's terrible advice in this particular case, where a glob in a for loop's list is by far the simplest and safest way to handle a directory of files (field splitting is not a concern since the glob is expanded during the penultimate step in shell command line processing, only quote removal follows it).
You are right about the glob expansion and field splitting but the problem but wrong about the line length limitation. I might have temed the problem not quite correctly with "arguments too loong", though. There is a maximum line length of an input line a shell can handle. The glob will expand before the shell even attempts to execute the command and so you might eventually hit the maximum line length of the shell. I have tested it (not using jot, though, as i don't have that tool) on AIX 5.x and some CentOS-system (don't know which kernel version, it was a 32-bit system) and the results with Korn Shell 88 are consistent (and as i expected).
The same phenomenon can be observed when using a command like "ls *" or "rm *" against a directory that big: the expansion of the glob will create an effective command line too long for the shell to digest.
Quote:
it will not properly handle any files which contain leading whitespace, embedded newlines, or a trailing backslash. The whitespace and trailing backslash can be fixed by tweaking IFS and using read's -r option. The embedded newline however cannot be worked around (at least not with any posix-compliant functionality in ls/read that I'm aware of).
This is correct for the most part of it. My script was suggested as a sketch towards a solution, not as a production-strength application. I should have said that, though, so your critizism is legitimate. The same goes for the directories not being created as they are filled.
Quote:
On an unrelated note, the following idiom will always return a 0 exit status, since when the exit command executes, the value of $? is the exit status of the [ command, which must have succeeded if the exit has been reached.
This is correct, an error on my part. I should have catched the return code in a variable, like i do it in my scripts usually.
Quote:
Please don't take the above criticisms personally; they are intended to be helpful.
You are welcome and no offense taken. It is the spirit of the board to learn collectively one from another and I'm neither perfect nor sacrosanct. In fact i welcome the possibility to gain insight from discussions like this and it is one prominent reason for me writing here.
bakunin
03-25-2010
