On 5/15/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
On 5/13/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
> The top level of a command line is list_concat() but it's not
> availiable otherwise.
set ar3 $ar1 $ar2
Well, that's a command.
> list_product() is availiable through braces but in a surprising way.
[reordered]
> [It is] sometimes useful: ``fgrep {-f,(ls *.words)}`` expands to
> ``fgrep -f some.words -f more.words``
How often is it useful, really?
Rarely. Most commands don't expect it to be readily availiable and
provide ways to just write multiple arguments where it's useful (e.g.
``command one kind of args -- other kind of args``).
You can achieve the fgrep expression as
fgrep -f' '{ls *.words}
I don't think that works. It looks the same, but fgrep would get
arguments containing spaces: '-f some.words' '-f other.words', which
won't work.
and handle cases with three arrays, inline as
for a in $arr1
for b in $arr2
for c in $arr3
echo $a\n$b\n$c
end
end
end
Verbose but works.
> Note that all implementations using external commands suffer from
> false splitting if any word contains newlines.
[...]
To avoid this, you can use "set newArray[$i] oldArray1[$j]", instead
of "echo".
> [...] I hacked perlish references int the flat data structures of fish.
[...]
Thinking of it next morning, I became rather ashamed of writing this
abomination :-). It seemed elegant in that moment - I now understand
better Larry's saying "Perl is worse than Python because people wanted
it worse"...
It's not enough to solve newline-sensitivity at command-line parsing
time. Any shell script relies on commands like `ls` and `grep`. To
really solve it, you must provide filesystem access and data
processing as part of the language - but then it's not a shell any
longer.
If we do want some newline-safety, we could special-case ``(...)``
containing builtins to get data directly from the builting rather than
as a list of strings. 'echo' would have to be a builtin. Then things
like ``foo (echo $bar $baz)`` would be magically safe. But I'm afraid
that's too fragile.
Or perhaps if ``(...)`` tried to split on null bytes before trying
newlines, it would provide enough practical safety with file names and
commands like ``find -print0``. This idea I actually like.
*Sigh* Unix should have outlawed newlines in file names...
--
Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
Governments are like kernels - everything possible should be done in user space.
