Re: Unix-ify File Names
Daniel Barclay <daniel@fgm.com>:
> Frank Terbeck wrote:
>> Daniel Barclay <daniel@fgm.com>:
>>> Frank Terbeck wrote:
>>>> Daniel B. <REMOVEdanielCAPS@fgm.com>:
[...]
>>> 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.
Then where is the point for the discussion? I am not telling anyone
to bring filenames with weird characters into their system. But it is
possible to support them if they are there.
If you do not know about the data you are dealing with, limiting the
code does not make sense. But I said that before.
[...]
>> 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.
I said GNU find didn't support it for quite some time.
But nevertheless, SUSv3 defined it before (and there is not just the
GNU version of find in this world).
The GNU find in etch supports it.
> Does the "+" make find invoke the command with multiple filenames at
> once?
Yes.
>>> 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?
See end of mail.
>> 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?
Yes. Otherwise you would have left the glob in there.
But you are narrowing the subject until it fits your argumentation.
> (By the way, why do keep sticking extraneous commas in the middle
> your sentences?)
No native English speaker here. Want to recommend a book about
grammar?
[...]
>>> 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.
No. 'eval' is a great tool and has its uses. But it does not make
loops easier, nor safer.
>> 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).
You do not know it. Otherwise you would know how the expansion in
for var in `foobar baz`
works, and not argue about 'loops do not support escaping'. Escaping
is a different topic, that does not apply here.
I will not continue the discussion just for the sake of it.
I think I have made my point clear by now.
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
Reply to: