On Tue, 14 Mar 2006, Florin Iucha wrote:
> On Tue, Mar 14, 2006 at 06:06:04PM -0600, Dave Sherohman wrote:
>> On Tue, Mar 14, 2006 at 04:03:00PM -0600, Florin Iucha wrote:
>>> On Tue, Mar 14, 2006 at 03:05:14PM -0600, Ed Wilts wrote:
>>>> Blanks in file names are evil...just pure evil.
>>>
>>> Why_do_you_say_that?_File_names_are_a_part_of_the_user_interface_and_why_should_I_bend_my_eyes_around_the_capabilities_(or_lack_thereof)_of_the_machine/program?_If_the_script_crashed_because_the_file_name_was_longer_than_14_characters_would_you_say_that_to_be_evil_as_well?
>>
>> Because the shell (or other command interpreter) needs to be able to
>> reliably distinguish characters which are part of an argument from
>> those which separate arguments. Given the command
>>
>> rm blackmail letter
>>
>> humans can't reliably determine whether the intent is to delete one
>> file named "blackmail letter" or two separate files named "blackmail"
>> and "letter", so how do you expect something as simple-minded as bash
>> to do so?
>
> Sure humans can, and bash can too. The meaning is unambiguous.
>
>> memory. Reliable determination of "this space is part of a filename,
>> that space separates filenames" is not readily solvable (and I tend
>> to suspect that it's not solvable at all).
>
> Ok, so the machine cannot guess which of the two conveniences I mean to
> request at a given moment. It is not an algorithmic problem - (think of
> touch instead of rm), so I expect a smart interactive shell to prompt me
> to disambiguate, yet to specifiy one mandatory separator in interpreted
> mode and be done with it.
I'm not sure I understand everything here (e.g., the reference to a
difference between how 'touch' and 'rm' handle spaces), but I think the
way to think about it is in terms of what our rules are for handling
spaces in command lines. The rule is that the space character is a
separator. So a command like this...
rm blackmail letter
...will attempt to delete two files in every shell I know of. To delete a
single file named "blackmail letter", we have to either escape the space
or use quotes:
rm blackmail\ letter
rm "blackmail letter"
rm 'blackmail letter'
All three of those commands do the same thing in both bash and tcsh, and
probably in quite a few other shells. I would not call this
"disambiguating" the command because there is nothing ambiguous about
this...
rm blackmail letter
...because it means "delete two files - one filename is 'blackmail' and
the other filename is 'letter'".
Are spaces in filenames evil? Well, they are annoying in many situations
but I would not call them evil.
No one has mentioned xargs. I think it is also worth looking at. Note
this argument in "man xargs":
--null, -0
Input filenames are terminated by a null character instead of by
whitespace, and the quotes and backslash are not special (every
character is taken literally). Disables the end of file string,
which is treated like any other argument. Useful when arguments
might contain white space, quote marks, or backslashes. The GNU
find -print0 option produces input suitable for this mode.
Then note these options in find:
-fprint0 file
True; like -print0 but write to file like -fprint.
-print0
True; print the full file name on the standard output, followed
by a null character. This allows file names that contain new-
lines to be correctly interpreted by programs that process the
find output.
This is part of the GNU/Linux way of coping with filenames that contain
spaces or even newlines. Yes, a filename can contain a newline. I just
made one and the behavior with ls can be a little weird, but here it is in
tcsh:
> touch 'bob\^Jjoe'
> ls
bob
joe
> ls -lAF
total 0
-rw-r----- 1 mbmiller users 0 Mar 15 00:28 bob?joe
In bash it is more predictable. It is also easier in bash to use rm to
get rid of the file. Another weirdness is that the ^J character is
produced using ctrl-M in tcsh but using ctrl-J in bash. In both shells
you have to hit ctrl-V before the other control character so that it is
processed properly.
This gives me yet another reason to switch from tcsh to bash!
Mike