From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: Avoiding the zshells intelligence...in one case
Date: Tue, 24 Jan 2017 10:21:28 -0800 [thread overview]
Message-ID: <ea629daa-2c59-5b41-4318-c73c5d99a54d@eastlink.ca> (raw)
In-Reply-To: <2f69cfec-46e2-1a93-101d-fb0579d0637f@gmx.com>
On 24/01/17 07:58 AM, Eric Cook wrote:
> And does so during both of those alias definitions, you may be
> confusing what happens
> during the definition of the alias and what happens during the execution of the alias.
>
> Running:
> % alias -L
>
> Will show you that both alias were defined exactly as you inputted them, because the single
> quotes prevented the expansions
Sure, but if we have any chains -- one command calling another -- we end
up loosing the quotes as things are passed along.
> And ignoring the expansions of the commandline, the original poster used an url that contains
> an ampersand; & isn't an expansion, just other shell syntax that a noglob-like option or bart's
> current attempts will not be able to disable.
And that's just what I'm saying -- it would be nice to have some sort of
bomb-proof zero expansion ability.
>
> % curl -s http://site?param&disown
> Can be a legal site url, but could also be meant as a curl command to be ran in the background and
> disown that process. short of reading the user's mind how would you make it easier?
> prepending noglob is already two more characters than '', then you would need an `nosyntax' like
> command to deactivate &.
My suggestions are really questions in disguise, it's interesting to
consider how any of this could really be done. All I know for sure is
that half or more of my own troubles with zsh have been efforts to stop
expansion of one thing or another, or to protect some character from
being interpreted or stripped out.
>
> I just don't see how remembering to use an alias/option is less inconvenient than remembering to use
> single quotes on strings with questionable characters.
Not convenient, that's hardly the point. More like predictability and
robustness and transparency. FWIW I've always thought that terseness in
code is a false virtue since it isn't typing that slows us down, but
design and debugging and -- where terseness is the rule -- just studying
up on the correct syntax can take a thousand times longer than the
actual keystrokes.
>
> hell, with recent versions of zsh with bracketed-paste you could copy and paste this entire email
> into your shell, invoke the quote-line widget, then prefix print -r -- and have a command that will
> work anywhere regardless of the options set (rcquotes being the sole exception) or alias/functions
> that the user may have.
True, there's almost always a way. Seems the only thing that's
impossible is passing a command's literal arguments to the command, tho
noglob is at least a partial cure for that. But, as time goes by, I
confess that more and more I see the virtues of zsh's way of looking at
things, but I do like pondering alternatives.
>
>
next prev parent reply other threads:[~2017-01-24 18:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 8:01 Meino.Cramer
2017-01-22 18:26 ` Bart Schaefer
2017-01-22 21:52 ` Martin Vaeth
2017-01-22 22:41 ` Bart Schaefer
2017-01-23 18:09 ` Martin Vaeth
2017-01-23 22:26 ` Bart Schaefer
2017-01-23 22:40 ` Ray Andrews
2017-01-24 2:48 ` Eric Cook
2017-01-24 5:42 ` Ray Andrews
2017-01-24 15:58 ` Eric Cook
2017-01-24 18:21 ` Ray Andrews [this message]
2017-01-24 22:31 ` Bart Schaefer
2017-01-25 1:19 ` Ray Andrews
2017-01-25 3:46 ` Bart Schaefer
2017-01-25 5:40 ` Ray Andrews
2017-01-25 16:50 ` Bart Schaefer
2017-01-25 4:56 ` Bart Schaefer
2017-01-25 5:47 ` Ray Andrews
2017-01-23 22:44 ` Bart Schaefer
2017-01-24 19:37 ` Martin Vaeth
2017-01-24 21:24 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea629daa-2c59-5b41-4318-c73c5d99a54d@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).