Martijn Dekker | 28 May 20:54 2015

getopts doesn't properly update OPTIND when called from function

I'm writing a shell function that extends the functionality of the
'getopts' builtin. For that to work, it is necessary to call the
'getopts' builtin from the shell function.

The POSIX standard specifies that OPTIND and OPTARG are global
variables, even though the positional parameters are local to the
function.[*] This makes it possible to call 'getopts' from a function by
simply passing the global positional parameters along by adding "$ <at> ".

My problem is that dash does not properly update the global OPTIND
variable when getopts is called from a function, which defeats my
function on dash. It updates the global OPTIND for the first option but
not for subsequent options, so OPTIND gets stuck on 3. (It does
accurately update the global OPTARG variable, though.)

I made a little test program that demonstrates this; see below the
footnote. It succeeds on bash, ksh93, pdksh, mksh, and yash, but not
(d)ash or zsh[*2].

The output of my test script seems consistent with the hypothesis that
OPTIND is reinitialized to 1 whenever a function is called. It should
only be initialized when the shell is initialized.

I suspect this is an old bug as other versions of ash, including Busybox
ash and NetBSD's /bin/sh, share it.

Thanks,

- Martijn

(Continue reading)

Fredrik Fornwall | 18 May 01:15 2015
Picon

[PATCH] Set LC_ALL instead LC_COLLATE in mkbuiltins

In mkbuiltins LC_COLLATE is set, but since "The value of the LC_ALL
environment variable has precedence over any of the other environment
variables starting with LC_"
(http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html), this
has no effect when LC_ALL is set.

This breaks when having e.g. LC_ALL=en_US.UTF-8 during make, which
causes the test case
    dash -c :
to fail, probably due to broken ordering in builtins.c. The patch
corrects that by setting LC_ALL instead of LC_COLLATE.

Fredrik

diff -u -r ../dash-0.5.8/src/mkbuiltins ./src/mkbuiltins
--- ../dash-0.5.8/src/mkbuiltins 2014-09-28 04:19:32.000000000 -0400
+++ ./src/mkbuiltins 2015-05-17 19:08:00.076452891 -0400
 <at>  <at>  -78,7 +78,7  <at>  <at> 
  if ($i ~ /^-/)
  line = $(++i) "\t" line
  print line
- }}' $temp | LC_COLLATE=C sort -k 1,1 | tee $temp2 | awk '{
+ }}' $temp | LC_ALL=C sort -k 1,1 | tee $temp2 | awk '{
  opt = ""
  if (NF > 2) {
  opt = substr($2, 2)
 <at>  <at>  -97,7 +97,7  <at>  <at> 
  */

 !
(Continue reading)

Alex Waite | 25 Mar 14:51 2015
Picon

Pattern matching faster than math

Hello,

This isn't a problem per-se, but I'm curious if anyone can shed some 
light on why this is so.

I have a script where I'm checking if the contents of a variable is an 
integer. An easy/hacky way to do this is

[ "$var" -ge 0 2> /dev/null ] || echo "is not int"

But this caused posh to segfault, so I went for a pattern matching 
solution instead:

[ -z "${var##*[!0-9]*}" ] && echo "is not int"

This works well, and it makes posh happy. But what's surprising to me is 
that it's faster.

I have more of a write-up in a commit message: 
https://github.com/zfsnap/zfsnap/commit/ed6326f0006ed18b7d8bb79d5ee8f06142847f41

Any thoughts or insight? Am I making some faulty assumption here?

Thanks for your time.

---Alex

--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

jacinta jacinta | 22 Mar 15:00 2015
Picon

greetings


HOW ARE YOU MY DEAR?

I, am miss jacinta,interested in you, and wish to have you as my friend,
please could you get back to me for more details of my self and all maybe
necessary in this relationship,including my picture,if this interest you
get back to me.email address(jacinta.jac <at> live.com)
yours jacinta

--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Damian Wrobel | 20 Jan 18:01 2015
Picon

Re: Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

On 01/20/2015 09:44 AM, Seb wrote:
> On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote:
>
> Hello,
>
>> I'm observing an inconsistent behaviour between:
>>   jobs
>> and
>>   echo "$(jobs)"
>
> It's because the command is ran in a sub-shell, where there is indeed no
> running job.
>
> Bash has a special mechanism to handle this and get the current shell
> context returned, that's why you may feel some inconsistency here (like
> I myself did :)

There is an application usage [1] where this case is specifically mentioned with 
a suggestion that: "For this reason, jobs is generally implemented as a shell 
regular built-in."

I basically planned to use the following construction to kill all running jobs:

$ kill $(jobs -p)

Now it looks that even the following doesn't work in a dash:

$ jobs -p | xargs kill

I would prefer not to code something like the following:
(Continue reading)

Damian Wrobel | 19 Jan 19:01 2015
Picon

Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

Hi,

I'm observing an inconsistent behaviour between:
  jobs
and
  echo "$(jobs)"

Here is the short example:

$ rpm -qv dash
dash-0.5.8-1.fc21.i686
$ /bin/dash
$ sleep 1000 &
$ jobs
[1] + Running                    sleep 1000
$ echo "$(jobs)"

$ echo `jobs`

$ jobs 2>/dev/null
[1] + Running                    sleep 1000
$

--

-- 
Have a nice day,
Damian
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Pádraig Brady | 15 Jan 18:40 2015

incorrect handling of quoted escapes

bash, ksh, zsh all support $'\n\x0a\012'

The POSIX discussion is at:
http://austingroupbugs.net/view.php?id=249

It would be great if dash supported it too.

I tested dash 0.5.8

thanks,
Pádraig
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Harald van Dijk | 9 Jan 18:17 2015
Picon

[PATCH] Fix variable assignments in function invocations

Hello all,

A long-standing problem with dash has been how it deals with variable 
assignments in function invocations, and several packages are affected 
by it, two I've come across recently being autogen and pkg-config (only 
their test suites, luckily).

A short test script:

   f() {
     echo inside f, VAR is $VAR
     sh -c 'echo inside sh called from f, VAR is $VAR'
   }

   VAR=value f
   echo after returning from f, VAR is $VAR

Assuming VAR was not already set, this should print (and does with bash):

   inside f, VAR is value
   inside sh called from f, VAR is value
   after returning from f, VAR is

With dash, this actually prints:

   inside f, VAR is value
   inside sh called from f, VAR is
   after returning from f, VAR is value

The first problem with that is that VAR does not get exported, the 
(Continue reading)

Herbert Xu | 31 Dec 21:56 2014
Picon
Picon

[EXPAND] Fixed "$ <at> " expansion when EXP_FULL is false

On Wed, Dec 31, 2014 at 07:03:30PM +0100, Juergen Daubert wrote:
> Hi,
> 
> today I tried to use dash from git as /bin/sh and run in a lot of
> problem I don't see with stable version 0.5.8. 
> After some investigations I narrowed it down to commit 
> 
> 3c06acdac0b1ba0e0acdda513a57ee6e31385dce 
> [EXPAND] Split unquoted $ <at> /$* correctly when IFS is set but empty
> 
> and related following to expand.c
> 
> 
> It seems that the changes to dash triggers, among others, some problem 
> with libtool.
> 
> As examples I've attached build logs for libpixman and kbd, there are a
> lot other builds that failed as well. If you need more, please let me 
> know.

Thanks for the report.  This patch should fix the problem.

-- >8 --
The commit 3c06acdac0b1ba0e0acdda513a57ee6e31385dce ([EXPAND]
Split unquoted $ <at> /$* correctly when IFS is set but empty) broke
the case where $ <at>  is in quotes and EXP_FULL is false.

In that case we should still emit IFS as field splitting is not
performed.

(Continue reading)

"Antonio Viñal" | 28 Dec 20:45 2014
Picon

Pease respond!

Pease respond!
Hello friend!
I wish to contact you personally for an important proposal that might
interest you.
I am sending this mail just to know if this email address is functional.
I have something absolutely essential to discuss with you. Contact me for
details through:
Email: barr.antoniovinal <at> yahoo.com.hk
with your direct contacts.
Yours faithfully.
Antonio Viñal.

--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Vadim Zeitlin | 23 Dec 23:34 2014

Possibly wrong handling of $_?

 Hello,

 I'm not exactly sure if this is a bug because I didn't find any
specification about how is this supposed to behave (to my surprise it
turned out that $_ was not in POSIX), but please consider this:

	% zsh -c 'echo -n foo && echo $_'
	foofoo
	% bash -c 'echo -n foo && echo $_'
	foofoo
	% dash -c 'echo -n foo && echo $_'
	foo/usr/bin/dash

I've tested several different versions of zsh (4 and 5) and bash (3 and 4)
and dash 0.5.5 and 0.5.7 from Debian and they all produced the results as
above.

 Shouldn't dash follow the other shells here?
VZ

Gmane