shopt, shopt -o (set -o) manage the same flag (interactive_comments)
Description: it's not a bug, but a strange behavior the flag interactive_comments is accessible from both shopt and shopt -o shopt | grep interactive_comments shopt -o | grep interactive_comments in your documentation (bashref), shopt -o (set -o) does not have this flag... thanks for your great job bye Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux presario 2.6.24.3vnl #1 PREEMPT Thu Apr 17 20:10:25 CEST 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release
wish list addition
read -t0 actually does nothing may be, could be used for -flushing pre-entered-key-buffer- while true do read -s -n1 -t0 x test $x && break echo "loop" done
eval, apparently inconsistent behavior
#!/bin/bash
a=( 1 2 3 )
b=( 4 5 6 )
x=a
eval b=( [EMAIL PROTECTED] )
echo [EMAIL PROTECTED]
#output:
#1 2 3
x=b
eval $x=( [EMAIL PROTECTED] )
#output:
#./tst: line 15: syntax error near unexpected token `('
#./tst: line 15: `eval $x=( [EMAIL PROTECTED] ) '
patch for bash-3.2 to compile under Debian GNU/Linux 4.0 with DietLibc
Here you are: mercurius:/usr/src/BadPenguin# cat bash-3.2-dietlibc.unified-patch --- build/bash-3.2/lib/sh/winsize.c.orig2006-07-28 05:57:45.0 +0200 +++ build/bash-3.2/lib/sh/winsize.c 2008-09-03 14:56:46.0 +0200 @@ -43,6 +43,11 @@ #include +/* Antonio Gallo , Dietlibc under Debian GNU/Linux declare winsize inside termios.h */ +#if !defined(winsize) +#include +#endif + /* Return the fd from which we are actually getting input. */ #define input_tty() (shell_tty != -1) ? shell_tty : fileno (stderr)
is it a bug? (little script)
#!/bin/bash -e trap "rm test_fifo" 0 mkfifo test_fifo ls / > test_fifo & exec 9<&0 while read dirname do echo $dirname # if I wait, exits!!! read -t 2 -p "press enter..." 0<&9 done < test_fifo exec 9<&- exit 0
tables - $'\x7f' does not loaded properly
$ a=( $'\x7e' $'\x7f' $'\x80' ) $ hexdump -C <(echo -n [EMAIL PROTECTED] ) 7e 20 01 7f 20 80 |~ .. .| 0006 bash puts two characters (\x01 and \x7f) instead of only one \x7f but... $ a[1]=$'\x7f' $ hexdump -C <(echo -n [EMAIL PROTECTED] ) 7e 20 7f 20 80|~ . .| 0005 may be its a bug... thanks for your job bye
variable scope
$ a=OUTSIDE
$ f1 () { local a=INSIDE; f2; }
$ f2 () { echo "before: $a";
unset a;
echo "after: $a"; }
$ f3 () { local a=INSIDE;
echo "before: $a";
unset a;
echo "after: $a"; }
$ f1
before: INSIDE
after: OUTSIDE
$ f3
before: INSIDE
after:
I can unset an 'external-local' variable, and then get his global scope
but I can't do the same with an 'internal-local' one
may be this is not perfectly coherent
(*imho*, local variables should not be seen in other functions...)
thanks for your job
bye
read + SIGWINCH - strange error
If I run this script in xterm, and I maximize (not resize) the window,
I'll get (nearly always) a very strange error... something like
./test: line 17: wait_for: No record of process 22659
but if I use 'read' without timing or with a very long time ( -t10 ) the
error does not raise.
---
#!/bin/bash
trap trapfunc SIGWINCH
trapfunc () {
for i in {1..1000}; do
tput cup 0 0
echo OK
done
}
clear
echo maximize your window
while true; do
read -sn1 -t1
done
--
Re: read + SIGWINCH - strange error
trap trapfunc SIGWINCH
trapfunc () {
for i in {1..1000}; do
tput cup 0 0
echo OK
done
}
I have used one thousand echoes only to assure error raising every time.
But you can use one hundred instead, and you will see the error raise
more rarely
Probably error raise (very very rarely) with only one echo too...
I think the error raise when read -t expire, and, at the same time, the
user have maximized his window and are writing something in SIGWINCH trap
If I'm on error, please let me know
best regards
is this coherent?
$ a=ok
$ b=a
$ echo ${!b-a}
ok
$ unset b
$ echo ${!b-a}
a
imho, the last command should expand to "ok" too
environment
$ declare +x x $ x=one $ ( echo $x; x=two; echo $x ) one two subshell inherits "x"? is this behavior coherent?
Re: environment
The environment is designed to be inherited. The subshell even inherits the shell variables. I 'm not sure what causes you trouble here or what it could be incoherent with? i think that $ ( echo $x ) is like $ bash -c 'echo $x' I'm on error... but I can't understand why
Re: Bash with colors?
Start at http://bash-hackers.org/wiki/doku.php/scripting/terminalcodes commands like "ls --color" does not use terminfo capabilities... $ hexdump -c <(TERM=xterm ls -d / --color=always) 000 033 [ 0 0 m 033 [ 0 1 ; 3 4 m / 033 [ 010 0 0 m \n 033 [ m 017 $ hexdump -c <(TERM=dumb ls -d / --color=always) 000 033 [ 0 0 m 033 [ 0 1 ; 3 4 m / 033 [ 010 0 0 m \n 033 [ m 017 ...use instead fixed strings (without regards about TERMinal) is this a good (and safe) choice too?
Re: Bash with colors?
commands like "ls --color" does not use terminfo capabilities...
...use instead fixed strings (without regards about TERMinal)
is this a good (and safe) choice too?
IMHO not. Too many assumptions. GNU ls seems to always assume an ANSI
terminal, regardless which TERM is set. Or did I miss something?
I have done a little search about how terminals uses "setaf"
$ find /usr/share/terminfo /lib/terminfo -type f | \
while read name
do
name=$(basename $name)
property=$(infocmp $name | grep -o "setaf=[^[:space:],]\+")
echo -n ${property:+$property - $name$'\n'}
done | \
sort |
less
a very very long list of terminals uses the same style of capabilities
are maybe the others simply "out-of-date"?
Re: Bash with colors?
And for the same reason some people hardcode the dot or the comma as thousands separator in their code, ignoring locale settings. "Never seen something different." what's the best? hardcoding, improving efficiency, and putting another brick on the wall of standardization.. ...or i18n/TERMinalization, improve complexity (and bug-risk), slow down performance and consolidation of the differences I can't answer to that question... but I see a lot of bash-code using hardcoding http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html http://tldp.org/LDP/abs/html/colorizing.html#AEN19341 may be, in the future, terminal differencies will disappear...
{# - strange behavior
$ a=$'\xd9\xbf'
$ echo ${#a}
1
$ a2=${a:0:1}
$ echo ${#a2}
1
this two characters are "j" and "k" graphical characters in linux
terminal/console
I need to extract only one... but apparently I can't.
Re: {# - strange behavior
Antonio Macchi wrote:
$ a=$'\xd9\xbf'
$ echo ${#a}
1
$ a2=${a:0:1}
$ echo ${#a2}
1
ops... I mean...
$ a2=${a:0:1}
$ hexdump -C <(echo $a2)
d9 bf 0a |...|
0003
seems bash can't break this two characters...
Re: {# - strange behavior
thanks... but parameters expansions and printf builtin works differently
about it...
$ locale | grep LC_CTYPE
LC_CTYPE="en_US.UTF-8"
$ a=eèèèe
$ b=e
$ echo ${#a}
5
$ echo ${#b}
5
$ printf "*%-10s*" $a
*eèèèe *
$ printf "*%-10s*" $b
*e *
is it ok?
Re: {# - strange behavior
Antonio Macchi wrote: thanks... but parameters expansions and printf builtin works differently about it... same problem with read... LC_CTYPE="en_US.UTF-8" $ read -n1 è $ hexdump -C <(echo -n $REPLY) c3|.| 0001 "è" is two chars but read stops at the first some commands works with and some others without regards about LC_CTYPE can this creates a bit of confusion?
[OT] mixed dialog boxes
hi thanks for your helps... I have written some code to create mixed dialog boxes, using a way roughly like object-oriented, i.e. using objects, properties and events. may be it can be useful to someone you can "take a look" using this link: http://www.webalice.it/antonio_macchi/sourcedialog.tar.bz2 the tar contains the source and some examples it has no license, so if you like it, feel free to do whatever you want with it best regards. antonio_mac...@alice.it
Re: {# - strange behavior
Yes, it's ok. Posix says that printf field widths are specified in number of bytes. I've never red nothing about POSIX, but imho, in the past, "char" and "byte" was synonymous maybe last POSIX definitions are very old...
[OT] graphic characters set
this command should starts the graphic character set (to create masks) $ tput smacs but, using aterm or Eterm, it does not work but it works using this form (lieing...) $ TERM=xterm tput smacs does anyone know where is the problem?
read + ^V
using ^V to pass an ascii character to read, the behavior is incoherent beetween simple read, and read -nx $ read ^V^A $ hd <(echo -n $REPLY) 01|.| 0001 $ read -n1 ^V $ hd <(echo -n $REPLY) 16|.| 0001 $ read -n2 ^V^A (30)[armada:xterm0]/home/user1 $ hd <(echo -n $REPLY) 16 01 |..| 0002 I'm on bash 3.2.39 so forgive me if in your new bash this "problem" does not arise bye
qwerty
$ printf "%s\n" ok - ok - why that score in the newline? $ printf "%d %s\n" 1 ok - 1 ok -bash: printf: -: invalid number 0 why getting error here, and not in the previous? why "invalid number" ? what is that zero? $ printf "%2s\n" qwerty qwerty strings larger than fixed-width are entire written? I'm using BASH_VERSION 3.2.39, so please forgive me if this issue are already fixed and thanks for your great job bye
Re: qwerty
There's nothing to fix. It might help if you provide some markers
sorry, and thanks for your patience...
in your test patterns so you can see where each argument begins and
ends, e.g.,
$ printf "(%d) {%s}\n" 1 ok -
(1) {ok}
-bash: printf: -: invalid number
(0) {}
... and for your trick!
bye
for i in {1..100000...
what's the rasonable limit in using this "compact" contruct, after which the for (( i=0; i<1000...; i++ )) became better?
Re: qwerty
I'm on error, I know... but, in your bash-ref guide you don't explain a lot printf and in man printf don't do it too... from man printf - NOTE: your shell may have its own version of printf, which usually supersedes the version described here. Please refer to your shell’s documentation for details about the options it supports. -
Re: qwerty
http://www.opengroup.org/onlinepubs/9699919799/utilities/printf.html#tag_20_94 (ouch!) ok! thanks!
printf "%q" and $'...'
Hi, I'm using older bash 3.2.39, so please forgiveme if in your newer
bash this issue does not arise.
0x00 and 0x0a has no output in printf "%q"
$ for i in {0..9} a; do printf "%q\n" "`echo -en \"\x0$i\"`"; done
''
$'\001'
$'\002'
$'\003'
$'\004'
$'\005'
$'\006'
$'\a'
$'\b'
$'\t'
''
$'\x00' outputs nothing
hd <(echo $'\x00')
0a|.|
0001
$'\x01' outputs twice.
$ hd <(echo -n $'\x01')
01 01 |..|
0002
thanks for your great job
have a nice day
(God Save Linux!)
bye
Re: printf "%q" and $'...'
it sounds strange, beacuse $ find . -print0 | while read -d $'\x00'; do touch "$REPLY"; done works fine. but if I try to "output" $'\x00', I can't.
Re: printf "%q" and $'...'
(Note blank line in the output -- one newline from the echo command, and one from the actual content of $myvar.) Using printf -v instead of x=$(printf) means you don't suffer from the trailing-newline-removal that command substitution does. I'm a bit puzzled by the original e-mail, though. I don't see what the actual goal is. If the goal is simply "put a newline character into a variable", then this is even simpler: myvar=$'\n' my goal is very very stupid, like this $ printf "%q" $(
Re: printf "%q" and $'...'
$ printf "\x00\n" | cat -A ^@ it works, so why... $ printf $'\x00' | cat -A $ ... not?
Re: printf "%q" and $'...'
When you run read -d $'\x00' what you're really doing is setting up a bunch of C-strings in memory like this: +-+-+-+-+--+- |r|e|a|d|\0| +-+-+-+-+--+- +-+-+--+- |-|d|\0| +-+-+--+- +--+--+- |\0|\0| +--+--+- WOW! but... $ printf one$'\x00'two\\n +-+-+-+-+-+-+--+ |p|r|i|n|t|f|\0| +-+-+-+-+-+-+--+ +-+-+-+--+-+-+-+--+--+ |o|n|e|\0|t|w|o|\n|\0| +-+-+-+--+-+-+-+--+--+ so the output should be "one", and stop here! but the real output is onetwo so, imho, there's something more... imadev:~$ echo $'foo\0bar' foo sorry... I'm a little bit confusing... look $ echo foo$'\0'bar foobar
Re: printf "%q" and $'...'
The answer is in the part you neglected to read. NULL can be passed to function only "escaped" \0 \x00 but $'\x00' is not like "\x00", because the first is expanded "before", and the second is expanded "after" $ printf $'\x00' +-+-+-+-+-+-+--+ +--+--+ |p|r|i|n|t|f|\0| |\0|\0| +-+-+-+-+-+-+--+ +--+--+ $ printf "\0" +-+-+-+-+-+-+--+ +--+-+--+ |p|r|i|n|t|f|\0| |\\|0|\0| +-+-+-+-+-+-+--+ +--+-+--+ right? if so, thanks a lot!
<( error
$ hd <(echo -en \\0{0..3}{0..7}{0..7})
it breaks the console.
Re: <( error
Also perhaps indicate what you want to achieve (I don't have an hd command, and didn't find a man page after a quick search) sorry.. i'll be more precise in future... but, if you don't have hd (hexdump) how can you see the content of a, for example, strange file i mean $ ls -l total 0 -rw-r--r-- 1 user1 user1 0 2009-11-28 14:56 ? $ hd <(ls) 09 0a |..| 0002 $ rm $'\x09' $ ls -l total 0 do you know another way to do it?
Re: <( error
Based on your question, I'm guessing you're in bash 3.2 or earlier, where
$ echo $BASH_VERSION
3.2.39(1)-release
$ cat /etc/issue
Debian GNU/Linux 5.0 \n \l
your "hd <(echo -en \\0{0..3}{0..7}{0..7})" is expanded as if you had typed
"hd <(echo -en \\) <(echo -en \\0001) <(echo -en \\0002) ..." and
runs into the FD exhaustion issue Chet already described.
thanks for this and your previous post.
bye
Re: operators available in bash versions
Gerard wrote: I apologize for asking what is probably a dumb question, but where can I find a definitive listing of what features are available in each version of Bash. For example, I only have access to Bash-4 on my system. I need to know if " $(< " also works on Bash < 4. I also have a few questions regarding array handling. I am running FreeBSD-7.2 and installed Bash via ports. could this be a good way to achive this? $ wget http://ftp.gnu.org/gnu/bash/bash-2.0.tar.gz --2009-11-30 19:08:52-- http://ftp.gnu.org/gnu/bash/bash-2.0.tar.gz Resolving ftp.gnu.org... 140.186.70.20 Connecting to ftp.gnu.org|140.186.70.20|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1349450 (1.3M) [application/x-tar] Saving to: `bash-2.0.tar.gz.1' 100%[==>] 1,349,450285K/s in 5.6s 2009-11-30 19:09:09 (237 KB/s) - `bash-2.0.tar.gz.1' saved [1349450/1349450] $ tar -zxf bash-2.0.tar.gz bash-2.0/doc/FAQ -O | grep "What.s new in version" 10) What's new in version 2.0? 10) What's new in version 2.0? $ wget http://ftp.gnu.org/gnu/bash/bash-3.0.tar.gz [etc.]
Re: IFS handling and read
Юрий Пухальский wrote:
Good day!
Theres is a problem with a following code:
echo a:b|IFS=: read a b; echo $a
this seems work
$ echo "a:b" | { IFS=":" read a b; echo $a; }
a
Re: best way to test for empty dir?
is_file()
{
[ -f "$1" ] && return
return 1
}
is_file /path/to/dir/* || echo empty
you don't need to check more than the first element
Re: best way to test for empty dir?
is_file()
{
[ -f "$1" ]
}
is_file /path/to/dir/* || echo empty
test is redundant too
---
this could be another way to accomplish this
empty_dir() {
eval test \" $1/* \" == \"" $1/* "\";
}
(excluding invisible files...)
Re: best way to test for empty dir?
[ -e "foo" -o -L "foo" -a ! -e "foo" ] it has no sense doing twice the "-e" test $ ln -s nonexistent foo $ [ -e "foo" -o -L "foo" -a ! -e "foo" ] && echo ok || echo ko ok $ [ -e "foo" -o -L "foo" ] && echo ok || echo ko ok as you can see, the first "-e" check imply the second one (aka, if the first "-e" is false, necessarily the second one will be true...) maybe you have "too rougly" join the trick to check a broken link -L "foo" -a ! -e "foo" but in this particular case you don't have to check "only" broken links, but every file, broken links included... so every file but broken links is "-e" links and broken links is "-L" join together -e and -L every file, included links and broken links ok? bye
