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

solsTiCe d'Hiver | 8 Dec 18:32 2014
Picon

"if [ s1 > s2 ]" broken, writing a s2 file

hello,
folowing that bug
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1400357,
I follow through to investigate and I found out
that whatever I try, when comparing 2 strings I always end up with a
file written to disk

From the man page
test expression
     [ expression ]
[...]
s1 > s2       True if string s1 comes after s2 based on the ASCII
value of their characters.

when I try to use it:
a="ert"
b="aze"
if [ $a > $b ] ; then
echo yes
fi
if [ "aer" > "azer" ] ;then
echo yes
fi

I got 2 yes printed on screen whereas only one should and most
importantly I got 2 empty files written to disk: one called "aze", and
another one "azer"

so this "if syntax" is broken or I don't knwo how to use it.

(Continue reading)

indeclinable04913 | 26 Nov 18:13 2014
Picon

Fix Penguin Penalty 17th October2014 ( mail-archive.com )

Dear Sir

Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin
Update? It is actually a code name for Google algorithm which aims at decreasing your websites search
engine rankings that violate Google’s guidelines by using black hat SEO techniques to rank your webpage
by giving number of spammy links to the page.

We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and
Panda. Our clients have survived all the previous and present updates with ease. They have never been hit
because we use 100% white hat SEO techniques to rank Webpages.  Simple thing that we do to keep websites away
from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers
to their queries.

If you are looking to increase the quality of your websites and to get more targeted traffic or save your
websites from these Google penalties email us back with your interest. 

We will be glad to serve you and help you grow your business.

Regards

Roshni Patel

SEO Manager ( TOB )
B7 Green Avenue, Amritsar 143001 Punjab
____________________________
NO CLICK in the subject to STOP EMAILS
--
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)


Gmane