All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jilles Tjoelker <jilles@stack.nl>
To: Vadim Zeitlin <vz-dash@zeitlins.org>
Cc: dash@vger.kernel.org, Harald van Dijk <harald@gigawatt.nl>
Subject: Re: Possibly wrong handling of $_?
Date: Thu, 25 Dec 2014 15:32:26 +0100	[thread overview]
Message-ID: <20141225143226.GA27266@stack.nl> (raw)
In-Reply-To: <E1Y3YxI-0004Qg-GA@smtp.tt-solutions.com>

On Wed, Dec 24, 2014 at 12:33:32AM +0100, Vadim Zeitlin wrote:
> On Wed, 24 Dec 2014 00:21:09 +0100 Harald van Dijk <harald@gigawatt.nl> wrote:

> HvD> On 23/12/2014 23:34, Vadim Zeitlin wrote:
> HvD> >   Hello,
> HvD> >
> HvD> >   I'm not exactly sure if this is a bug because I didn't find any
> HvD> > specification about how is this supposed to behave (to my surprise it
> HvD> > turned out that $_ was not in POSIX), but please consider this:
> HvD> >
> HvD> > 	% zsh -c 'echo -n foo && echo $_'
> HvD> > 	foofoo
> HvD> > 	% bash -c 'echo -n foo && echo $_'
> HvD> > 	foofoo
> HvD> > 	% dash -c 'echo -n foo && echo $_'
> HvD> > 	foo/usr/bin/dash
> HvD> 
> HvD> This does come across as somewhat confusing, but $_ is really not a 
> HvD> special variable at all in dash.

>  Ah, this does explain it, thanks!

Dash does implement $_, but only in interactive mode.

Your selection of shells makes it appear as if dash is the odd one out,
but in fact it is not. FreeBSD /bin/sh (also an Almquist shell
derivative), mksh and ksh93 also only implement $_ in interactive mode.
Details of how $_ differ as well, particularly in ksh93. It seems unwise
to use this feature in scripts.

> HvD> If dash did something special with $_, then I agree it would be nice if 
> HvD> it would be somewhat compatible with other shells. If dash simply does 
> HvD> not implement a feature, that feature is not required by any standard, 
> HvD> and that feature is not widely used, then I suspect there won't be a lot 
> HvD> of interest in implementing that feature.

>  Yes, I understand, somehow the idea that dash didn't implement it at all
> just didn't occur to me, but clearly adding a non-standard new feature is
> not nowhere near as important as fixing [what looked like] a bug. I'm not
> sure about the "not widely part", but I don't have any non-anecdotal
> evidence one way or the other.

> HvD> Don't be put off by that, though. You are free, of course, if you feel 
> HvD> so, to attempt to convince people $_ is an important feature that all 
> HvD> shells should implement. If you have compelling use cases, if it solves 
> HvD> real problems, and if many other shells already implement it, you might 
> HvD> even get it standardised. I have never seen a need for it, but that's 
> HvD> just me speaking from personal experience, others may feel differently.

>  FWIW my initial problem started with using

> 	builddir := $(shell mkdir -p some-long-make-expression && echo $_)

> in a makefile, which seemed like a nice way to assign the value to the
> variable only if the directory was successfully created. This can, of
> course, be done in a myriad of other ways, but this one just seemed like
> the most elegant to me. Whether this counts as a "need" or not is not for
> me to say.

>  Personally I'd say the main argument for adding support for "$_" to dash
> would be to avoid mysterious problems like the one I just had because dash
> silently (i.e. without giving any errors) behaves differently from the
> other shells, which in my case resulted in the makefile misbehaving only
> under Debian (where dash is used as /bin/sh) but not under systems.

Such a principle of least surprise is not a design goal for dash.

-- 
Jilles Tjoelker

  reply	other threads:[~2014-12-25 14:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-23 22:34 Possibly wrong handling of $_? Vadim Zeitlin
2014-12-23 23:21 ` Harald van Dijk
2014-12-23 23:33   ` Re[2]: " Vadim Zeitlin
2014-12-25 14:32     ` Jilles Tjoelker [this message]
2014-12-25 22:05       ` Harald van Dijk

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=20141225143226.GA27266@stack.nl \
    --to=jilles@stack.nl \
    --cc=dash@vger.kernel.org \
    --cc=harald@gigawatt.nl \
    --cc=vz-dash@zeitlins.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.