On Tue, Apr 6, 2010 at 02:38, Isaac Dupree <[email protected]> wrote: > > (incidentally, in bash, you can change the space-expansion handling by > changing IFS -- splitting only on newlines, and not splitting on > anything at all, are options. Hmm, I never thought of the idea of > setting IFS in my .bashrc to change the bash interactive experience..hmm!)
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#ifs has good advice on changing IFS to make bash more robust. (the rest of the article is not relevant here - it argues that banning weird characters from filenames would be nice. > (ideally, I'd think an annotation about how you wanted an expansion to > be split would be best placed on the expansion (or maybe on the whole > word-to-be-split). But then syntax would have to be invented... for > (bad) example: $[split=space]variable This is a bad example conceptually, as fish never splits variables. Pardon me if you fully understand this, but I can't leave it unclarified: In fish, we deal with only 2 data forms: a single string, or an array of strings. We want to minimize conversions (splitting/joining) between them, and to be able to override how they are performed. - Input from commands/streams comes is originally a SINGLE string. - Environment variables are SINGLE strings. - Wildcard globbing is also a kind of input, producing an ARRAY of filenames. - Intermediate storage in fish - variables - are always ARRAYs (though frequently used to store a single string). - The main kind of output in a shell is giving a command an ARRAY of arguments. As you see, fish mostly works with arrays, with little conversion needed. In particular, passing a variable to a command is a 1:1 mapping, with no splitting involved! The most flexible way to allow non-standard splitting/joining in a shell is to let commands (or functions) do it. On the output side, this is easy - you give an array to e.g. printf, it produces a single string. On the input side, (command) substitution is the obvious way to use commands, but the result is just a single string. This is the motivation for splitting by \n by default - to use commands to produce arrays. Just a few pieces are missing: - A way to use to perform custom splitting by running a command. This must allow arbitrary characters (even newlines) inside a single value. - Taking a command's output as a single string, without splitting. This could be implemented by a custom splitting command (that allways takes the whole string as one part). - Joining an array into one string. This could be implemented by command substitution, if there is a way to take the output as one string. I claim that \0 cannot appear inside array elements; even if fish did support \0-safe strings, it cannot be passed as argument to any command, making it totally useless in a shell. => Therefore, I propose that if a command output contains \0, fish should split by it; if not, it should split by \n. This would allow custom splitting commands to be written (and work nicely with find -print0). E.g. the following functions: function whole tr -d '\0' # strip \0s because they're unrepresentable in a single string printf '\0' end allow use of (command | whole) to substitute command's output as one string, and (command | whole | tr ',' '\0') is a correct (I think) way to split by only commas. [A proper command that splits by a specified separator would be desired.] I've previously advocated enhancing ``echo`` for controlled joining and ``read`` for controlled splitting. That works easily becase ``read`` directly writes to a variable, so its output can be an array. But the \0 solution [+ a convenient splitting command] is more flexible. As for "$var" and "(command)" syntaxes, they'd just be syntax sugars for something like (echo --sep=" " $var) and (command | whole). We can have them for convenience and familiarity, but now I won't care much if we just dropped them. As for "$var", I weakly prefer it to join with colons instead of spaces, to easily get back the original form enviroment variables like $PATH. -- Beni Cherniavsky-Paskin <[email protected]> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
