zsh-users
 help / color / mirror / code / Atom feed
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.
>
>


  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).