DASH Shell discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox