Re: Unix-ify File Names
Frank Terbeck wrote:
Daniel Barclay <daniel@fgm.com>:
Frank Terbeck wrote:
Daniel B. <REMOVEdanielCAPS@fgm.com>:
Frank Terbeck wrote:
Mike McClain <mike.mcclain@nowhere.net>:
Frank Terbeck <ft@bewatermyfriend.org> wrote:
...
... people think spaces are bad in filenames.
(They are not bad, ...
In what sense are they not bad? ... However, they and other
special characters do make it more difficult to handle arbitrary file
names.
No. They are never bad. It just takes a bit of practice to get used to
do things in a robust way.
But some common Unix tools aren't robust enough, in the sense of
providing consistent escape/encoding mechanisms to handle special
characters.
For example, Emacs' tags files use commas as delimiters, and (last I
knew) don't have an escape/encoding mechansim for representing a comma
_in_ a file name, so (again, last I knew) a Linux kernel file with
a comma in its name doesn't get processed right.
So? Just because there are programs that limit the namespace of the
files they are working with (which is _absolutely_ okay), does not
mean, that shell scripts must obey to these programs' behaviours.
How did you infer that I was arguing that the shells should follow
those programs' behaviors? I wasn't arguing for that.
I was pointing out that using shell-special characters in filenames
was (somewhat) bad--it triggers problems with non-robust programs.
Some commands do provide fully general mechanisms. (For example,
find's -print0 and xargs' -0 option can handle any possible file
pathname, including one with newline characters.) However, many
commands do not. That typically makes it very difficult to
handle "special" characters.
...
Btw: xargs is not needed if your find binary is reasonably POSIX
compliant. Just use '+' instead of ';' with the -exec option. (Yes, I
know that GNU find didn't support this for quite some time.)
Which version of find supports that? My (Sarge) system's man page
for find doesn't seem to mention it yet.
Does the "+" make find invoke the command with multiple filenames at
once?
However, what about the general case?
It sounds like for i in `...` doesn't have an escaping/encoding
mechanism that is sufficient to handle both (unescaped) asterisks
that represent wildcards and escaped/encoded asterisks that represent
literal asterists.
I don't think you really understand, what is happening here.
[snip]
% foo='bar\ baz' ; % for i in `echo "$foo"` ; do echo "($i)" ; done
(bar\)
(baz)
[snap]
You _cannot_ escape things there.
So how am I misunderstanding it? (I said it sounds like the shell
for loop doesn't support escaping. You said one cannot escape
things there. Those statements are consistent with each other.
So how am I not understanding it?
You see, this is not the type of thing, you want to teach beginners.
Hence, 'for i in `...`' loops should be avoided by beginners (did you
realize, that you dropped 'ls *glob*' from the backtick expression?
Yes. Did you realize that I was trying to talk about cases that are
more general that just globbing done by the shell?
(By the way, why do keep sticking extraneous commas in the middle
your sentences?)
What about when one is building up a command string in a variable,
say CMD, and then executing the assembled command via "$CMD"?
The string contained in the variable is parsed as a normal command,
right? So any logical string values that contain shell-special
characters needs to be encoded with the usual shell escape-sequence
syntax, right?
(E.g., if I want to delete a file named "xx*yy", I would have to type
something like:
rm xx\*yy
on a manual command line, so if I wanted the command line
$CMD
to execute that same rm command, CMD would have to contain the
string "rm xx\*yy" (e.g., set by the command line:
CMD="rm xx\\*yy"
)
[...]
Is there any such command (or, say, built-in function)?
It sounds like you are looking for 'eval'.
Yes, that does seem like the easier (and safer) ("right") way.
But this has got noting to do with the original subject.
And this misunderstanding leads me to the conclusion, that you should
read up on how various expansions in POSIX shells work (and probably
on a few common pitfalls, like maximum size of arguments for external
processes, too.);
Yeah, I know about that one (well, that there is a limit, if not
details).
> No offence.
Next time, you might want to avoid telling something they don't
understand for the things you then immediately proceed to show
they have already understood.
Daniel
--
Reply to: