Linux: bash 'declare -f' adds trailing whitespaces to output

2007-09-25 Thread Jari Aalto

Tested in:

GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
GNU bash, version 3.2.25(16)-release (i686-pc-cygwin)

An example:

function testfunc ()
{
echo "this is test"
}

>From shell:

$ declare -f | grep testfunc -A 3 | cat -A

Result; notice the trailing whitespaces in output:

testfunc () $
{ $
echo "this is test"$
}$

Jari
-- 
Welcome to FOSS revolution: we fix and modify until it shines




Re: Linux: bash 'declare -f' adds trailing whitespaces to output

2007-09-25 Thread Jan Schampera

Jari Aalto wrote:


testfunc () $
{ $
echo "this is test"$
}$


Just a thought:
It looks like there is a system behind it. So I guess it's some parser 
thing that needs it like that.


However, just guessing.

Jan





Re: Linux: bash 'declare -f' adds trailing whitespaces to output

2007-09-25 Thread Chet Ramey
Jari Aalto wrote:
> Tested in:
> 
> GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
> GNU bash, version 3.2.25(16)-release (i686-pc-cygwin)
> 
> An example:
> 
> function testfunc ()
> {
> echo "this is test"
> }
> 
> From shell:
> 
> $ declare -f | grep testfunc -A 3 | cat -A
> 
> Result; notice the trailing whitespaces in output:

It doesn't change the declaration or the semantics.  How is it a
problem?

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/




Re: Linux: bash 'declare -f' adds trailing whitespaces to output

2007-09-25 Thread Jari Aalto
* Tue 2007-09-25 Chet Ramey  INBOX
> Jari Aalto wrote:
>
>> Tested in:
>> 
>> GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
>> GNU bash, version 3.2.25(16)-release (i686-pc-cygwin)
>> 
>> An example:
>> 
>> function testfunc ()
>> {
>> echo "this is test"
>> }
>> 
>> From shell:
>> 
>> $ declare -f | grep testfunc -A 3 | cat -A
>> 
>> Result; notice the trailing whitespaces in output:
>
> It doesn't change the declaration or the semantics.  How is it a
> problem?

It smells like a bug to output trailing spaces for some lines and not
some others.(*)

Jari

(*) I sometimes "record" anvironment state and git does not like
trailing spaces for a good reason.

-- 
Welcome to FOSS revolution: we fix and modify until it shines




Turning off job control doesn't make async jobs ignore SIGINT

2007-09-25 Thread AnMaster
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=k8 -pipe -O2 -msse3
uname output: Linux tux 2.6.22-gentoo-r5 #1 Mon Aug 27 18:24:02 CEST 2007 
x86_64 AMD Sempron(tm) Processor 3300+ AuthenticAMD GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 3.2
Patch Level: 17
Release Status: release

Description:
>From man bash:
   Non-builtin  commands  run by bash have signal handlers set to the 
values inherited by the shell from its parent.
   When job control is not in effect, asynchronous commands ignore SIGINT 
and SIGQUIT in addition to these inherited
   handlers.   Commands  run  as  a result of command substitution ignore 
the keyboard-generated job control signals
   SIGTTIN, SIGTTOU, and SIGTSTP.

This doesn't seem to be the case. When job control is not in effect, async jobs 
still get SIGINT sent to them even if
SIGINT is sent to the main process.

As far as I can see I should get "After quit" printed out and netcat should not 
have died before the trap got run.

After asking for this in #bash on irc.freenode.net
<@greycat> The man page says "When job control is not in effect, asynchronous 
commands ignore SIGINT and SIGQUIT as well."
<@greycat> My initial testing with #!/bin/bash   set +mnc gateway 25 &   
wait Doesn't work, though.  Ctrl-C kills both.
I also got told I should report a bug using bashbug.

Repeat-By:
$ cat > test.sh
#!/bin/bash
set +m
trap 'echo got INT; ps aux | grep "$PID"; echo QUIT >&3; echo After quit' INT
mkfifo /tmp/in
mkfifo /tmp/out
nc irc.kuonet-ng.org 6667 < /tmp/out > /tmp/in &
PID="$!"
exec 3>/tmp/out
exec 4

scripting help

2007-09-25 Thread suser

I am trying to create a script to go through /etc/passwd and change anyone
who's home directory is "/mnt/home" to "/mnt/". I
have been playing around with loops and regular expressions but have not got
anything close to the results i want. I have roughly 1000 users so changing
them all by hand is quite the pain.

so basically im trying to do something like the following:

Original - user:x:1000:100:user:/mnt/home:/bin/bash

what i want - user:x:1000:100:user:/mnt/user:/bin/bash

any suggestions? thanks in advance!
-- 
View this message in context: 
http://www.nabble.com/scripting-help-tf4517825.html#a12887532
Sent from the Gnu - Bash mailing list archive at Nabble.com.





Re: Turning off job control doesn't make async jobs ignore SIGINT

2007-09-25 Thread Andreas Schwab
AnMaster <[EMAIL PROTECTED]> writes:

>>From man bash:
>Non-builtin  commands  run by bash have signal handlers set to the 
> values inherited by the shell from its parent.
>When job control is not in effect, asynchronous commands ignore SIGINT 
> and SIGQUIT in addition to these inherited
>handlers.   Commands  run  as  a result of command substitution ignore 
> the keyboard-generated job control signals
>SIGTTIN, SIGTTOU, and SIGTSTP.

That paragraph is only relevant for interactive shells and keyboard
generated signals.  See also
.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: scripting help

2007-09-25 Thread Andreas Schwab
suser <[EMAIL PROTECTED]> writes:

> I am trying to create a script to go through /etc/passwd and change anyone
> who's home directory is "/mnt/home" to "/mnt/".

This does not really has anything to do with bash, let alone with bugs
in bash, so it is rather off-topic here.

> Original - user:x:1000:100:user:/mnt/home:/bin/bash
>
> what i want - user:x:1000:100:user:/mnt/user:/bin/bash
>
> any suggestions? thanks in advance!

$ awk -F: '$6 == "/mnt/home" { $6 = "/mnt/" $1 }' < input > output

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Re: scripting help

2007-09-25 Thread The Wanderer

Reply addresses set by hand to work around broken defaults. (Again.)

suser wrote:


I am trying to create a script to go through /etc/passwd and change
anyone who's home directory is "/mnt/home" to "/mnt/". I have been playing around with loops and regular
expressions but have not got anything close to the results i want. I
have roughly 1000 users so changing them all by hand is quite the
pain.

so basically im trying to do something like the following:

Original - user:x:1000:100:user:/mnt/home:/bin/bash

what i want - user:x:1000:100:user:/mnt/user:/bin/bash

any suggestions? thanks in advance!


This is not really a bash-related question as far as I can tell.

I would probably do that with sed, e.g.

sed /etc/passwd -e "s/100:\([^:]*\):\/mnt\/home:/\1:\/mnt\/\1:/g"

or equivalently (I think) but more tersely

sed /etc/passwd -e "s/100:\([^:]*\)\(:\/mnt\/\)home/\1\2\1/g"

You could, of course, add the '-i' flag to have sed make the changes to
the file in place - but I would recommend, instead, redirecting the
output into a separate file and confirming that it is correct, then
copying the new file into place.

--
  The Wanderer sticks his neck out again

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.




Re: Turning off job control doesn't make async jobs ignore SIGINT

2007-09-25 Thread Chet Ramey
AnMaster wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
> -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=k8 -pipe -O2 -msse3
> uname output: Linux tux 2.6.22-gentoo-r5 #1 Mon Aug 27 18:24:02 CEST 2007 
> x86_64 AMD Sempron(tm) Processor 3300+ AuthenticAMD GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 3.2
> Patch Level: 17
> Release Status: release
> 
> Description:
> From man bash:
>Non-builtin  commands  run by bash have signal handlers set to the 
> values inherited by the shell from its parent.
>When job control is not in effect, asynchronous commands ignore SIGINT 
> and SIGQUIT in addition to these inherited
>handlers.   Commands  run  as  a result of command substitution ignore 
> the keyboard-generated job control signals
>SIGTTIN, SIGTTOU, and SIGTSTP.
> 
> This doesn't seem to be the case. When job control is not in effect, async 
> jobs still get SIGINT sent to them even if
> SIGINT is sent to the main process.

I can't reproduce this with bash-3.2.25 on Mac OS X.  Using the following
somewhat simplified version of your script:

set +m
echo $$

trap 'echo INT; ps auxww | grep $pid ; echo QUIT >&4' INT

{
trap 'echo subshell INT; exit 1' INT;
sleep 100
} &
pid=$!

exec 4>/tmp/OUT

wait
echo after wait

cat /tmp/OUT

kill -0 $pid
kill $pid

rm -f /tmp/OUT
exit 0

I get some variation of the following output whether I use ^C or send
SIGINT from another shell:

19591
INT
chet 19592   0.0 -0.029232404  p1  S+9:35PM   0:00.00
../bash-3.2-patched/bash ./x3
chet 19595   0.0 -0.027372428  p1  S+9:35PM   0:00.01 grep
19592
after wait
QUIT
./x3: line 22: 19592 Terminated  { trap 'echo subshell INT;
exit 1' INT; sleep 100; }

A system call tracer would probably give you more insight into what's
happening to your script.  If I had to guess, I'd guess that nc is
terminating because the process at the other end of the named pipe
terminates before nc reads from it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/