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
kabe | 22 Dec 06:50 2014
Picon

[PATCH] create builtins.c properly on old cpp

Encontered this on ancient gcc-2.95.3 environment;
src/builtins.def.in -> src/builtins.def generation emitted
^ $
lines (likely by /* */), which where NOT ignored by 
src/mkbuiltins and generating bogus builtins.c.

-- kabe

diff -U6 -p dash-0.5.8/src/mkbuiltins.dist dash-0.5.8/src/mkbuiltins
--- dash-0.5.8/src/mkbuiltins.dist	Sun Sep 28 17:19:32 2014
+++ dash-0.5.8/src/mkbuiltins	Mon Dec 22 14:36:43 2014
 <at>  <at>  -66,13 +66,13  <at>  <at>  cat <<\!
  */

 #include "shell.h"
 #include "builtins.h"

 !
-< $builtins sed '/^#/d; /^$/d' > $temp
+< $builtins sed '/^#/d; /^ *$/d' > $temp
 awk '{	printf "int %s(int, char **);\n", $1}' $temp
 echo '
 const struct builtincmd builtincmd[] = {'
 awk '{	for (i = 2 ; i <= NF ; i++) {
 		line = $i "\t" $1
 		if ($i ~ /^-/)
--
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)

RECEIVE YOUR ATM CARD BEFORE 23RD OF DECEMBER 2014

THIS ACCESS BANK PLC WANT TO INFORM YOU THAT YOUR ATM CARD IS READY, THAT IF YOU NEED IT, YOU MUST PAY THE $98. IF
YOU ARE READY, MAKE SURE YOU SEND ME YOUR FULL NAMES AND YOUR DIRECT TELEPHONE NUMBER FOR ME TO CALL YOU SO
THAT YOU CAN PAY DIRECTLY TO OUR ACCOUNT OFFICER.

Thanks,

DR. CHRIS MICHAEL
FROM ACCESS BANK PLC
E-MAIL: accessb575 <at> gmail.com
--
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


Gmane