Re: left bit shift (<<) operator now demands line continuation
On 01/27/2010 08:34 PM, j...@horde.net wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: 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../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux boost 2.6.31-17-server #54-Ubuntu SMP Thu Dec 10 18:06:56
UTC 2009 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
bash 4.0 fails to parse a function that's parsed successfully by dash(1) as
well as older versions of bash (3.1, 3.2):
[...@boost:pts/6 ~> cat inet
swap32_posix()
{
local funcname=swap32_posix
local arg
for arg in "$@"; do
echo $((
($arg& 4278190080)>> 24 |
($arg& 16711680)>> 8 |
($arg& 65280)<< 8 |
($arg& 255)<< 24
))
done
}
[...@boost:pts/6 ~> bash -n inet
inet: line 6: unexpected EOF while looking for matching `)'
inet: line 14: syntax error: unexpected end of file
[...@boost:pts/6 ~> dash -n inet
[...@boost:pts/6 ~>
Repeat-By:
This affects the *left* bit shift operator, but *not* the right bit shift
operator:
[...@boost:pts/6 ~> cat left.sh
echo $((2<< 1
))
[...@boost:pts/6 ~> bash -n left.sh
left.sh: line 1: unexpected EOF while looking for matching `)'
left.sh: line 3: syntax error: unexpected end of file
[...@boost:pts/6 ~> cat right.sh
echo $((1>> 2
))
[...@boost:pts/6 ~> bash -n right.sh
[...@boost:pts/6 ~>
4.1.2(1)-release is also affected
RR
Re: Sort: problem with option -f
On Jan 28, 8:43 am, Guido Milanese wrote: > I am facing a problem concerning SORT on a Linux Ubuntu 9.04 > distribution. > I noticed that the -f option seems not to work. This is an example: > DOG > CAT > zebra > dog > ZEBRA > mouse > > Running "sort" on the file I get: > CAT > dog > DOG > mouse > zebra > ZEBRA > > Running "sort -f " I get the same result. No problem of encoding, being > plane letters <127 -- to be sure I saved the list as 'test', and "file > test" says it's a pure ASCII text. Without the '-f' option, 'sort' used to > distinguish among lowercase / uppercase. > Is this a bug or a new behaviour of 'sort' ? > > Thanks! > guido > guido.milan...@unicatt.itwww.arsantiqua.org This has little or nothing to do with Bash. Try this: LANG=C sort
Re: Sort: problem with option -f
2010-01-28, 09:40(-08), DennisW: > On Jan 28, 8:43 am, Guido Milanese wrote: >> I am facing a problem concerning SORT on a Linux Ubuntu 9.04 >> distribution. >> I noticed that the -f option seems not to work. This is an example: >> DOG >> CAT >> zebra >> dog >> ZEBRA >> mouse >> >> Running "sort" on the file I get: >> CAT >> dog >> DOG >> mouse >> zebra >> ZEBRA >> >> Running "sort -f " I get the same result. No problem of encoding, being >> plane letters <127 -- to be sure I saved the list as 'test', and "file >> test" says it's a pure ASCII text. Without the '-f' option, 'sort' used to >> distinguish among lowercase / uppercase. >> Is this a bug or a new behaviour of 'sort' ? [...] > This has little or nothing to do with Bash. > > Try this: > > LANG=C sort Not guaranteed to work, in this case it's the LC_COLLATE part that matters. The LC_COLLATE variable takes precedence over LANG, and LC_ALL over LC_COLLATE, so: LC_ALL=C sort is guaranteed to work as nothing has precedence of LC_ALL. It does have the side effect to also change the LC_MESSAGES setting and therefore the language of sort's error messages (but setting LANG could have that effect as well). There's no easy work-around that. You could do things like: ( set -a eval "$(locale)" unset LC_ALL LC_COLLATE=C LC_CTYPE=C exec sort file ) You've got to have the same LC_COLLATE as LC_CTYPE otherwise the behavior is unspecified, and if you reset LC_CTYPE, then the error messages may be displayed in the right language, but not the right character set. That localisation thing is not really well designed IMO. -- Stéphane
Re: Sort: problem with option -f
2010-01-28, 18:05(+00), Guido Milanese: > On Thu, 28 Jan 2010 09:40:47 -0800, DennisW wrote: > >> This has little or nothing to do with Bash. > Sorry. I assumed that this group was the place to discuss bash commands. > Where can I ask, if this is not the correct group? I ask because I have > another question concerning SORT. It's to discuss the bash command (which is a shell, a command line interpreter), not the other commands that that command may run. firefox and openoffice are examples of other commands like sort that you may have bash run, they can't all be discussed here. However, "sort" is part of the standard Unix toolkit, so comp.unix.shell is probably a good place to ask that question. If you want to discuss things specific to the GNU implementation of sort, you can go to gnu.utils.help. That question is a bit of a FAQ though, so you could have looked it up beforehand. It's also explained in the sort documentation (at least GNU sort's one). >> Try this: >> LANG=C sort > Thanks, it works! [...] It won't work if the LC_ALL or LC_COLLATE environment variables are set though. -- Stéphane
Bash sometimes cannot find aliases
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 -mtune=generic -O2 -pipe uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 23:30:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 2 Release Status: release Description: When I attempt to run an alias, Bash occasionally says the command is not found. Re-running the command generally succeeds. This also occurs with aliases that are named after existing programs. For example, running "ls", which is aliased to "ls --color", occasionally results in "ls" being run without the "--color" argument (the alias is bypassed). Repeat-By: This problem seems to occur once every few hundred aliased commands I run. It seems more frequent immediately after sourcing a .bashrc file. I cannot reproduce it with a loop that repeatedly runs an aliased command. Is this a known issue? I may be able to help debug this (perhaps by modifying my build to log state when a command is not found). Thanks -Dan
Sort: problem with option -f
I am facing a problem concerning SORT on a Linux Ubuntu 9.04 distribution. I noticed that the -f option seems not to work. This is an example: DOG CAT zebra dog ZEBRA mouse Running "sort" on the file I get: CAT dog DOG mouse zebra ZEBRA Running "sort -f " I get the same result. No problem of encoding, being plane letters <127 -- to be sure I saved the list as 'test', and "file test" says it's a pure ASCII text. Without the '-f' option, 'sort' used to distinguish among lowercase / uppercase. Is this a bug or a new behaviour of 'sort' ? Thanks! guido guido.milan...@unicatt.it www.arsantiqua.org
Re: Sort: problem with option -f
On Thu, 28 Jan 2010 09:40:47 -0800, DennisW wrote: > This has little or nothing to do with Bash. Sorry. I assumed that this group was the place to discuss bash commands. Where can I ask, if this is not the correct group? I ask because I have another question concerning SORT. > Try this: > LANG=C sort Thanks, it works! gm -- Guido Milanese -- www.arsantiqua.org
Re: Bash sometimes cannot find aliases
On 1/28/10 3:55 AM, Dan Zwell wrote: > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > When I attempt to run an alias, Bash occasionally says the command > is not found. Re-running the command generally succeeds. This also > occurs with aliases that are named after existing programs. For example, > running "ls", which is aliased to "ls --color", occasionally results in > "ls" being run without the "--color" argument (the alias is bypassed). > > Repeat-By: > This problem seems to occur once every few hundred aliased commands > I run. It seems more frequent immediately after sourcing a .bashrc file. > I cannot reproduce it with a loop that repeatedly runs an aliased command. > > Is this a known issue? I may be able to help debug this (perhaps by > modifying my build to log state when a command is not found). This is not a known issue. If you can provide me a way to reliably reproduce it, then I can look at a possible problem and fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: left bit shift (<<) operator now demands line continuation
On 1/27/10 2:34 PM, j...@horde.net wrote:
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
> bash 4.0 fails to parse a function that's parsed successfully by dash(1) as
> well as older versions of bash (3.1, 3.2):
>
> [...@boost:pts/6 ~> cat inet
> swap32_posix()
> {
> local funcname=swap32_posix
> local arg
> for arg in "$@"; do
> echo $((
> ($arg & 4278190080) >> 24 |
> ($arg & 16711680) >> 8 |
> ($arg & 65280) << 8 |
> ($arg & 255) << 24
> ))
> done
> }
> [...@boost:pts/6 ~> bash -n inet
> inet: line 6: unexpected EOF while looking for matching `)'
> inet: line 14: syntax error: unexpected end of file
> [...@boost:pts/6 ~> dash -n inet
> [...@boost:pts/6 ~>
This is a tricky one. Before bash-4.0, bash "parsed" $(...) command
substitutions by counting parens, making sure they matched, and hoping
for the best. This was not Posix conformant and the source of a number
of bug reports -- Posix says that the shell should be able to handle
"any valid shell script" regardless of the number of unmatched parens
when parsing a command substitution -- but more or less worked.
Beginning with bash-4.0, I changed bash to be more rigorous about parsing
the contents of $(...), for Posix conformance and to eliminate the need
for users to resort to things like (pattern-list) in a case statement. I
had to make a choice at that point: should command substitution or
arithmetic expansion take precedence? It's an issue because Posix also
says that the shell needs to handle nested subshells ( $((a);(b)) )
without prioritizing. I chose to have the contents of $(...) parsed as
a command to support the "any valid shell script" part of the standard.
That works pretty well.
It fails when you have tokens composed of the same characters but with
different meanings in a command and expression context. The `<<' in your
example is one of those. (In fact, if you replace the << with <, your
arithmetic expansion is a valid command as well as a valid expression.)
After a lot of discussion last month, the Posix working group acknowledged
that we have to change the standard, and it looks like we will choose to
specify that $(( always introduces an arithmetic expansion, as long as the
$((...)) encloses a valid arithmetic expression. I will probably change
bash-4.2 to implement that regardless of the state of the standard at that
point.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: GPL incompatibility? examples/loadables/getconf.c
Thanks, everyone, for the responses! Very useful. I'm studying open source licensing at the University of Victoria, BC, Canada, and these responses were great. yours, Julius On Mon, Dec 28, 2009 at 8:52 AM, Chet Ramey wrote: > On 12/25/09 8:28 PM, Julius Davies wrote: >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' >> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' >> -DCONF_VENDOR='pc' -DLOCALEDI$ >> uname output: Linux flower 2.6.31-1-amd64 #1 SMP Mon Nov 16 04:44:38 >> UTC 2009 x86_64 GNU/Linux >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 4.0 >> Patch Level: 33 >> Release Status: release >> >> Description: >> >> This file in the source contains a BSD license with an advertising clause: >> >> bash-4.0/examples/loadables/getconf.c >> >> >> I'm curious if this is a problem, since Bash is mostly GPL version 3 (or >> later). > > It's a loadable builtin. It has to be built separately and loaded with > enable -f. And it's an example, for pete's sake. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ > -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/logging.html
Re: Bash sometimes cannot find aliases
On Jan 28, 2:55 am, Dan Zwell wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' > -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 > -mtune=generic -O2 -pipe > uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 > 23:30:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > GenuineIntel GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > When I attempt to run an alias, Bash occasionally says the command is > not found. Re-running the command generally succeeds. This also occurs > with aliases that are named after existing programs. For example, > running "ls", which is aliased to "ls --color", occasionally results in > "ls" being run without the "--color" argument (the alias is bypassed). > > Repeat-By: > This problem seems to occur once every few hundred aliased commands I > run. It seems more frequent immediately after sourcing a .bashrc file. I > cannot reproduce it with a loop that repeatedly runs an aliased command. > > Is this a known issue? I may be able to help debug this (perhaps by > modifying my build to log state when a command is not found). > > Thanks > -Dan I can think of two ways to bypass an alias that will produce the behavior you describe. These are by design. Perhaps the issue you are experiencing is related or perhaps not. /tmp$ alias alias ls='ls --color=always' /tmp$ ls /tmp$ \ls /tmp$ command ls /tmp$ alias p=pwd /tmp$ p /tmp /tmp$ \p p: command not found /tmp$ command p p: command not found /tmp$ echo \\ > backslash /tmp$ . ./backslash /tmp$ p p: command not found /tmp$ p /tmp So perhaps the file you are sourcing has a stray backslash at the end.
Re: Sort: problem with option -f
On Thu, 28 Jan 2010 18:24:15 +, Stephane CHAZELAS wrote: > However, "sort" is part of the standard Unix toolkit, so comp.unix.shell > is probably a good place to ask that question. If you want to discuss > things specific to the GNU implementation of sort, you can go to > gnu.utils.help. Thanks for your kind explanation. I assumed that in a 'bash' group also the basic Unix commands might be discussed. I'll ask in the other groups. And also thanks for your comments in your other post! gm -- Guido Milanese -- www.arsantiqua.org
Re: Bash sometimes cannot find aliases
On 01/28/2010 02:28 PM, Chet Ramey wrote: On 1/28/10 3:55 AM, Dan Zwell wrote: Bash Version: 4.1 Patch Level: 2 Release Status: release Description: When I attempt to run an alias, Bash occasionally says the command is not found. This is not a known issue. If you can provide me a way to reliably reproduce it, then I can look at a possible problem and fix. Chet Thanks, Chet. I'll let you know if I learn how to reliably reproduce this, or if I learn the cause. -Dan
Re: Bash sometimes cannot find aliases
On Thu, Jan 28, 2010 at 4:55 PM, Dan Zwell wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' > -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 > -mtune=generic -O2 -pipe > uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 23:30:46 > CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel > GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: >When I attempt to run an alias, Bash occasionally says the command > is not found. Re-running the command generally succeeds. This also occurs > with aliases that are named after existing programs. For example, running > "ls", which is aliased to "ls --color", occasionally results in "ls" being > run without the "--color" argument (the alias is bypassed). > > Repeat-By: >This problem seems to occur once every few hundred aliased commands > I run. It seems more frequent immediately after sourcing a .bashrc file. I > cannot reproduce it with a loop that repeatedly runs an aliased command. > > Is this a known issue? I may be able to help debug this (perhaps by > modifying my build to log state when a command is not found). > > I have the same problem. It's not 4.1 specific. I don't know how to reproduce it either but I can see it from time to time. > Thanks > -Dan > > >
Any guide about writing my own bash built-in commands?
Hi all, I want to write my own built-in bash commands but I cannot find any info about that in bash manual. Anyone has any idea? Thanks. -Clark
Re: Any guide about writing my own bash built-in commands?
On Fri, Jan 29, 2010 at 1:39 PM, Renjun Wang wrote: > I just put the shell scripts I write into $PATH,it works well > > That's not what I want to do. I want to make my own built-in commands (like `alias', `cd') other than external bash scripts. > 2010/1/28 Clark J. Wang > > Hi all, >> >> I want to write my own built-in bash commands but I cannot find any info >> about that in bash manual. Anyone has any idea? >> >> Thanks. >> >> -Clark >> > >
Re: Any guide about writing my own bash built-in commands?
On Thu, Jan 28, 2010 at 08:42:25PM EST, Clark J. Wang wrote: > Hi all, > I want to write my own built-in bash commands but I cannot find any > info about that in bash manual. Anyone has any idea? Never done that myself but I found this excellent introductory article: http://cfajohnson.com/shell/articles/dynamically-loadable/ Should provide an entry-point for further research. CJ
