Re: Expanding quotes

[Yuri D'Elia <wavexx@thregr.org>]

On 12/24/2013 06:18 PM, Ray Andrews wrote:
> I prefer simplicity with some resulting limitations on what can be done,
> over complicated efforts to do 'anything'.  It's just as Bart said, some
> issues are better left 'unsolved'. The solution could be worse than the 
> problem.  I think back to my DOS days, where almost all of the 'special'
> characters were reserved--it sure made things simpler.

I think you're conflating the text UI of a shell, the filesystem and the
shell language itself as part of the same issue. Yes, taken together, I
do agree that from my user point of view it's definitely inconvenient
and the interaction is not ideal. However, I would gladly prefer a shell
solution than "fixing" what's clearly not broken: the filesystem.

If you use a visual file manager, users will curse your from not being
allowed to use quotes and spaces as part of the file name. I know
windows users complain all the time about the disallowed characters,
because they don't see the reasons of the restricted character set
anymore (this is true also for users of nautilus/gnome/kde of course). I
also agree with these users.

> And mine ;-) I come at this, not as a zsh expert, but as a guy who knows
> something about information theory. Noam Chomsky would have something to
> say about this sort of issue.

The line-editing interface has definitely limitations, but I would
always like to think about it just as one of the possible interfaces to
the file system.

Imagine a different shell, where you had to different insertion modes,
like "vi". To enter a path, you would enter "pathname" mode with ESCp,
and the shell would keep track internally of the beginning and end of
the file name, while just showing the path maybe in a different color:

% some-command ESCppath name with spacesESCc continue command

Problem solved without escaping entirely?
(damn, I would love such a shell).