Re: bash doesn't display tabs for tabs -- ignores tabstops.

Greg Wooledge wrote: > On Sun, Apr 21, 2013 at 12:25:20AM -0700, Linda Walsh wrote: >> If I 'reedit my last "statement", it indents 8 spaces/tab. > > What does this sentence mean? I am completely stumped. What is > the sequence of steps you are actually p

bash doesn't display tabs for tabs -- ignores tabstops.

I don't use it that often, but only recently discovered that linux compat terminals can set their tabstops. So one can set tabstops to match their code-indentation -- this allows the benefit of letting others be able to change tab stops if they want more or less indenting (vs. using space+tabs, --

Re: Found problem mentioned in email 3/27: path interpretted/eval'd as numeric expression

Chris Down wrote: > On 2013-04-17 17:30, Linda Walsh wrote: >> BTW, is it planned to implement exporting ARRAY and HASHES? >> >> Sure would simplify some programs... ;-) > > As if exporting functions wasn't hacky enough... But then the functio

Re: Logical operators in arithmetic evaluation: documentation vs implementation

and...@coolbox.se wrote: > On Thu, Apr 18, 2013 at 12:02:55PM -0500, Dan Douglas wrote: >> 10 factorial (bash/ksh93/zsh): >> >> $ f=n=n?n--*f:1 let n=10 f > bash: let: n=n?n--*f:1: expression recursion level exceeded (error token is > "n?n--*f:1") >> $ echo "$n" > 0 --- Hmmm...works here

Re: Bash4: Problem retrieving "$?" when running with "-e"

Chet Ramey wrote: > > There has been extensive discussion of the changes to -e between bash-3.2 > and bash-4.0, which brought bash closer to Posix. Bash wasn't totally > Posix-conformant until bash-4.2. What I don't understand is why this change in functionality wasn't limited to POSIX

Found problem mentioned in email 3/27: path interpretted/eval'd as numeric expression

I'm leaning toward the side of this not being a bug, BUT is it really this way?? Really seems a buried "gotcha" and maybe behavior should be reconsidered if this is desirable. I have a function "include", that looks along my PATH for the file. One might ask why shopt -s sourcepath doesn't work:

Re: invoke tilde expansion on quoted string

Greg Wooledge wrote: > On Sun, Apr 07, 2013 at 01:13:09AM -0700, Linda Walsh wrote: >>> getent passwd 'Domain Administrator' >> Domain Administrator:x:500:18:Domain Admin accnt:/home/root:/bin/bash > > getent(1) is fine where it's available, but it'

Re: invoke tilde expansion on quoted string

Eric Blake wrote: > Even if your system allows shell metacharacters in usernames, tilde > expansion does not. I never thought of that -- I seemed like there should be a get command that access the appropriate library by using your systems's configuration. Unfortunately, it looks like i

Re: weird problem -- path interpretted/eval'd as numeric expression

John Kearney wrote: > Am 29.03.2013 18:53, schrieb Linda Walsh: >> Greg Wooledge wrote: >>> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote: >>>>include was designed to search the path for functions that >>>> are relative paths. While

Re: weird problem -- path interpretted/eval'd as numeric expression

Greg Wooledge wrote: > On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote: >> include was designed to search the path for functions that >> are relative paths. While the normal sourcepath allows searching for >> filenames on the search path, I don't belie

Re: weird problem -- path interpretted/eval'd as numeric expression

Dan Douglas wrote: > Can you whittle this down to the smallest reproducer and post a stand-alone > synthetic testcase with sample input data that fails? If I had a clue how to do that, I would, that's why I mentioned that that **NORMALLY** it works fine. include was designe

Re: weird problem -- path interpretted/eval'd as numeric expression

Greg Wooledge wrote: > On Wed, Mar 27, 2013 at 02:37:16PM -0700, Linda Walsh wrote: >> Greg Wooledge wrote: >>>>> Array variables may not (yet) be exported. >>> Associative arrays can't be exported either. > >> Yeah, but they seem to

Re: weird problem -- path interpretted/eval'd as numeric expression

Greg Wooledge wrote: > On Wed, Mar 27, 2013 at 01:25:53PM -0700, Linda Walsh wrote: >> Greg Wooledge wrote: >>> Arrays cannot be exported. The bash manual explicitly says so: >>> >>> Array variables may not (yet) be exported. >> === >>

Re: weird problem -- path interpretted/eval'd as numeric expression

Greg Wooledge wrote: > On Wed, Mar 27, 2013 at 12:17:21PM -0700, Linda Walsh wrote: >> dcl -x _SPATH >> dcl -xa _FPATH >> dcl -xA _INC > > Arrays cannot be exported. The bash manual explicitly says so: > > Array variables may not (yet) be exported. ===

Re: weird problem -- path interpretted/eval'd as numeric expression

Greg Wooledge wrote: > We would need to see the definition of the "include" function, and the > contents of the file that it's presumably sourcing or whatever. > Working on packaging, but to answer your immediate questions: Assuming attachments work, 'include' is in ~/bin Note, some of these fi

weird problem -- path interpretted/eval'd as numeric expression

Not sure if this is the correct forum for this, as I am very uncertain that it is a bash-bug and am more inclined to believe it is some odd interpretation causing my code to go hay-wire in this instance. So if I should move this to another discussion location, I'm fine with that -- I'm just trying

Re: Bug/limitation in 'time' (kernel setings?)...

1) Why not use your 'null' program, which in your blog, you state makes little difference. 2) Better, why not use the simple 'fork'/exit' which doesn't call a separate program; (that's one reason for switching to perl or better, would be C; Note the perl prog: #!/usr/bin/perl die "need count" u

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > The reply below is way too long, but oh well. > > The summary is: > I am 100% certain that my ExprCount() loop is CPU bound. Your stats claim 530 iterations/second when spawning expr. That's ~2ms/process create. In an article from 14 years ago on a 200Mhz Pen

Re: Bug/limitation in 'time' (kernel setings?)...

Linda Walsh wrote: > > Bruce Dawson wrote: >> How many CPUs do you have? 20% usage doesn't mean anything without knowing >> that. On a five-core system 20% usage would imply one full core. --- Another tool to check out if you have it is 'qps'... it can show

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > How many CPUs do you have? 20% usage doesn't mean anything without knowing > that. On a five-core system 20% usage would imply one full core. --- If you look at the example that shows no process spawning overhead, it shows 100% cpu usage. 100%=1CPU, regardless of co

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > Hmmm -- again, that doesn't match what I see. bash is suspended while it > waits for expr to run, and the instant that expr completes bash runs again. > This can be seen in the profiler screenshot. The CPU is busy at all times, > and always busy on exactly one process. ---

Re: Bug/limitation in 'time' (kernel setings?)...

I think you misunderstand...what Pierre is saying -- your process is scheduled out to give others a *chance* to run and the scheduler isn't called often enough to roll you back in immediately when it finds out that no one else needs their time ticks... That's why I mentioned all of the scheduling

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='$ > uname output: Linux Ubuntu1m 3.2.0-35-generic-p

Re: Should this be this way?

Chet Ramey wrote: > On 3/1/13 5:04 PM, Linda Walsh wrote: >> >> Chet Ramey wrote: >>> Your vendor, which may be SuSE, has changed bash and shipped the modified >>> version. >> >> Supposedly this has to do with memory corruption problems in &g

Re: Bug/limitation in 'time'

Chris Down wrote: > On 2013-03-18 00:46, Linda Walsh wrote: >> Bruce Dawson wrote: >>> Chris Down pointed that out. My loop now looks like this -- portable (I >>> believe) and fast: >>> >>> BashCount() { >>> for (( i = $1 ; i > 0 ; i-

Re: Bug/limitation in 'time'

Bruce Dawson wrote: > Chris Down pointed that out. My loop now looks like this -- portable (I > believe) and fast: > > BashCount() { > for (( i = $1 ; i > 0 ; i-- )); do > : > done > echo Just did $1 iterations using bash math > } To do the above, you'd want to pre-init

Re: Bug/limitation in 'time'

Bruce Dawson wrote: > Yep, we've changed our loops to use roughly that syntax. Unfortunately a lot > of online resources recommend the $(expr) technique. My understanding is > that using $(expr) is more portable, because i-- is bash specific, but I > don't really know. but $((i-=1)) isn't Bash s

If rbash is worthless, why not remove it and decrease bloat?

et Ramey wrote: > On 3/14/13 2:52 AM, Linda Walsh wrote: >> Is 'rbash' not part of POSIX? > Posix has chosen not to standardize the restricted shell, either `rsh' or > `set -r'. I had the erroneous belief that 'rbash' was something useful to so

Re: ignoring current shell and always running posix shell? Re: Should this be this way?

Chet Ramey wrote: > The default bash behavior and the SuSE modification are both conformant. Is 'rbash' not part of POSIX? I.e. if I run in a restricted shell, it is consider POSIX compliant to elevate the user to /bin/sh when executing unlabeled script lines? Sorta makes the idea

Re: ignoring current shell and always running posix shell? Re: Should this be this way?

Pierre Gaston wrote: >> >> >> It is likely that the document is assuming you are running on >> a POSIX compliant system where all users use the same shell so there is >> only 1 shell, thus the use of the word 'the' when referring to the shell. >> > Of course, it's the posix specificati

ignoring current shell and always running posix shell? Re: Should this be this way?

Pierre Gaston wrote: > On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus wrote: >> I think the line above will produce unspecified behavior. > Man bash says: > If this execution fails because the file is not in executable > format, and the file is not a directory, it is assumed to be a shell > scr

Re: gnu parallel in the bash manual

John Kearney wrote: > The example is bad anyway as you normally don't want to parallelize disk > io , due to seek overhead and io bottle neck congestion. This example > will be slower and more likely to damage your disk than simply using mv > on its own. but thats another discussion. ---

Re: Should this be this way?

Chet Ramey wrote: > Your vendor, which may be SuSE, has changed bash and shipped the modified > version. Supposedly this has to do with memory corruption problems in 4.2 and the "possibility" that it might come back... Is this likely to be a problem? Dr. Werner Fink wrote: > The patch bel

Re: Should this be this way?

Chet Ramey wrote: > On 2/27/13 11:05 PM, Linda Walsh wrote: >> >> Greg Wooledge wrote: >>>> How often, when at a terminal, do you type #!/bin/bash before every line? >>> When I've put the contents into a file? Every. single. time. >> --- >>

Re: Should this be this way?

Greg Wooledge wrote: > > How often, when at a terminal, do you type #!/bin/bash before every line? > > When I've put the contents into a file? Every. single. time. --- Then when I press 'v' to edit the command line in a text editor -- maybe 'bash' should insert such a line? It's converted your

Re: Should this be this way?

Chet Ramey wrote: > > Your vendor, which may be SuSE, has changed bash and shipped the modified > version. Sorry for the bother. I reported the problem in the proper venue... (thanks)..

Re: Should this be this way?

Greg Wooledge wrote: > POSIX specifies the behavior of a shell. This tells Chet how he has to > make Bash behave (with some leeway). There are all kinds of silly little > details and ambiguities that Chet has to worry about. > > However, YOU as a shell script writer do not have to worry about

Re: Should this be this way?

Chet Ramey wrote: > On 2/26/13 12:41 AM, Linda Walsh wrote: > >> It isn't using the current value of SHELL as my shell nor the value >> of my login shell. > > It uses $0 (or, rather, the basename of $0), which is initialized from > the parent shell's

Re: Should this be this way?

Chris Down wrote: > On 2013-02-25 18:27, Linda Walsh wrote: >> I mentioned that everything in my ENV and usage pointed at /bin/bash. > > You gave $SHELL, which is not really relevant (it doesn't necessarily > reference > your login shell, or your current shell either)

Re: gnu parallel in the bash manual

Chet Ramey wrote: > On 2/25/13 8:07 PM, Linda Walsh wrote: >> Chet Ramey wrote: >>> On 2/16/13 3:50 AM, Pierre Gaston wrote: >>>> I don't quite see the point of having gnu parallel discussed in the >>>> bash reference manual. >>> I was

Re: Should this be this way?

DJ Mills wrote: > On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh <mailto:b...@tlinx.org>> wrote: > > You didn't answer the question... how did you call the script? > > ''sh script'' ? --- I typed the script name interactively on the command line

Re: Should this be this way?

Sorry, forgot: > bash --version GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu) > uname -a Linux Ishtar 3.7.6-Isht-Van #4 SMP PREEMPT Thu Feb 7 01:34:39 PST 2013 x86_64 x86_64 x86_64 GNU/Linux --- I just can see why it should execute differently... very weird.

Re: gnu parallel in the bash manual

Chet Ramey wrote: > On 2/16/13 3:50 AM, Pierre Gaston wrote: >> I don't quite see the point of having gnu parallel discussed in the >> bash reference manual. > I was asked to add that in May, 2010 by Ole Tange and Richard Stallman. Maybe now that it was done, it can be removed? Or did they as

Should this be this way?

My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well. Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash. I had the foll0wing script which acts differently based on whether or not it has a #!/bin/bash at the top: (i.e., as it is displayed below, it fails; on

Re: Q on Bash's self-documented POSIX compliance...

Clark WANG wrote: I think every POSIX compatible shell has its own extensions so there's no guarantee that a script which works fine in shell A would still work in shell B even if both A and B are POSIX compatible unless the script writer only uses POSIX compatible features. Is there a pure

Re: |& in bash?

Bob Proulx wrote: And therefore they don't know how to write other directory traversal tasks either. find . -type f -exec sed -n '/PATTERN/s/THIS/THAT/gp' {} + --- You mean I can't: "sed -Rn '...'" ? Drat. OB.bash: bash -c 'while (($#)); do [[ -f $1 ]] && sed -n "/PATTERN/s/THIS/THA

Q on Bash's self-documented POSIX compliance...

I noted on the bash man page that it says it will start in posix compliance mode when started as 'sh' (/bin/sh). What does that mean about bash extensions like arrays and use of [[]]? Those are currently not-POSIX (but due to both Bash and Ksh having them, some think that such features are part

Re: How does one disable completion when nothing but tabs or spaces is on the line?

Chet Ramey wrote: On 1/5/13 8:36 PM, Linda Walsh wrote: Chet Ramey wrote: OK, if readline as it currently exists doesn't offer the feature you want, why not take a shot at writing it? You might find that others like it as well, though none of them have spoken up so far.

Re: How does one disable completion when nothing but tabs or spaces is on the line?

Chet Ramey wrote: OK, if readline as it currently exists doesn't offer the feature you want, why not take a shot at writing it? You might find that others like it as well, though none of them have spoken up so far. This feature used to exist in 3.0. You "fixed it" to only work

Re: How does one disable completion when nothing but tabs or spaces is on the line?

Chet Ramey wrote: On 12/31/12 4:48 PM, Linda A. Walsh wrote: If I have nothing but tabs or spaces on a line, how do I disable completion but have it return the char typed? (space or tab) -- and if bash is looking for a command, then execute any command. If you don't want TAB to perform

bug-bash@gnu.org

Dan Douglas wrote: On Sunday, October 14, 2012 05:21:05 PM Linda Walsh wrote: Seriously -- why not just fix it? If you think it is broken -- Fix it. This should fix most scripts. case $- in *e*) exec /bin/sh -c 'cat; rm -f "$1"; exit 1' -- "$BASH_SOURCE

bug-bash@gnu.org

Steven W. Orr wrote: On 10/12/12 06:55, quoth Sergey Fadeev: Why doesn't it exit the shell? $ set -e $ echo $(false) Shouldn't the error code of $(false) command substitution be checked by set -e before passing stdout to the echo builtin? Isn't it the most logical behavior that most p

RFE: enable lost functionality: Re: How to turn off command completion on empty line?

Given this can't be done... RFE? To regain 3.x compatible behavior? Is compatibility a bad thing for some reason? Linda Walsh wrote: How do you turn off command completion on an empty line? no_empty_cmd_completion only works when you are not in the middle of a command but if you

How to turn off command completion on empty line?

How do you turn off command completion on an empty line? no_empty_cmd_completion only works when you are not in the middle of a command but if you type something like declare -A var=( [val]="" the char in pasted source causes bash to corrupt input. Bash eats up characters and doesn't take

Re: a recursion bug

Greg Wooledge wrote: On Tue, Oct 02, 2012 at 10:01:43AM -0700, Linda Walsh wrote: On 9/28/12 9:54 AM, Yuxiang Cao wrote: test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes (8359936 bytes allocated) Why shouldn't bash fail at the point it hits resource exhaustio

Re: square bracket vs. curly brace character ranges

Chet Ramey wrote: http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html The above relies upon a hack to the algorithm -- use *USEFUL* hack in most cases, but still a hack. when I type locale I get: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.U

Re: a recursion bug

Chet Ramey wrote: On 9/28/12 9:54 AM, Yuxiang Cao wrote: I use ulimit -s to find stack size, which is 8192kbytes. Then I use valgrind to record the stack size which give me this information. test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes (8359936 bytes allocated

Re: Unicode collation for readline completion in bash

Rob Hoelz wrote: Hello, I have an idea for a new feature for bash/readline, and I wanted to get the community's feedback before I go about implementing it. --- Have you looked at the Unicode collation algorithm? They have one published with each released. You say you

Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1))

Chet Ramey wrote: That's fine -- if the error message points at the included file as "not returning a > 'true' value. It doesn't. It points to a conditional in the previous file. Note that the error message wasn't generated by bash: you generated it yourself based on $BASH_COMMAND and the

Re: bash giving wrong message for indicated failure (was Re: Unhelpful behaviors in 4.2.10(1))

weird --- End File2 (sdf2) Execution output: $ sdf Error executing "[[ $# -ge 2 ]]" in "main" <<<- wrong statement at "./sdf", line "4" (level=0) <<<- wrong file & line # --- =

Re: Unhelpful behaviors in 4.2.10(1)

Chet Ramey wrote: On 6/9/12 3:05 AM, Linda Walsh wrote: To sum up ". sdf2" is returning 1 Bash considers . to be a simple command even though what's really executed is [[ $# -ge 2 ]] && echo hello. --- Right It's NOT a simple command. To be clear: `.&#

Re: Unhelpful behaviors in 4.2.10(1)

Pierre Gaston wrote: trap backtrace ERR set -T To sum up ". sdf2" is returning 1 Bash considers . to be a simple command even though what's really executed is [[ $# -ge 2 ]] && echo hello. --- Right It's NOT a simple command. I am trapping on ERR, not 'anything' that

Unhelpful behaviors in 4.2.10(1)

File1: sdf: Ishtar:/tmp> more sdf #!/bin/bash _prgpth="${0:?}"; _prg="${_prgpth##*}"; _prgdr="${_prgpth%/$_prg}" [[ -z $_prgdr || $_prg == $_prgdr ]] && $_prgdr="$PWD" export PATH="$_prgdr/lib:$_prgdr:$PATH" shopt -s expand_aliases extglob sourcepath ; set -o pipefail . backtrace.shh . sdf2 ---

Re: req for fix: Completion: inconsistent case correction and '/' appending(for dirs)

Chet Ramey wrote: On 5/31/12 3:56 PM, Linda Walsh wrote: if I type in a path: (1st example) ls -d /share/doc/new, bash displays: ls /share/doc/New\ Folder Pressing 'Enter' gets: ls: cannot access /share/doc/New Folder: No such file or directory vs. (2nd example) ls /sh

Re: Red-Hat Bug 825751 - bash-completion fails on environment variables

Eric Blake wrote: On 06/07/2012 03:22 PM, Linda Walsh wrote: This isn't a matter of preference... its a real bug. Ex: $ ls $HOME/bin "ls: cannot access $HOME/bin: No such file or directory" Yes, we know. Ergo patch 29: According to the the referred to dis

Re: Red-Hat Bug 825751 - bash-completion fails on environment variables

Clark WANG wrote: On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg wrote: Actual results: ls \$HOME/ Already discussed for quite a few times. :) For example: http://lists.gnu.org/archive/html/bug-bash/2011-12/msg00079.html (patched attached) http://lists.gnu.org/archive/html/bug-bash/201

Indirect access to variables, including arrays (was Re: Compare 2 arrays.)

Greg Wooledge wrote: The only Bourne-family shell that can manipulate arrays whose names are passed to a function is ksh93, with its "nameref" command. Bash has nothing analogous to that yet. = I don't understand. Are you saying that ${!nameofvar} isnt' supported? I need a fun

Re: Incorrect mangling of multiline array assignment in history

Davide Brini wrote: Fix: No idea! Work-around: try setting shopt -s lithist

Re: .bashrc is sourced even for non-interactive shells (when run from sshd)

Pierre Gaston wrote: In all your examples the shell will be called like: bash -c 'isatty 0 2'. If you use a bash compiled with the above option you can add 'ps -p$$ -ocmd' at the top of your .bashrc to verify it. They are all non-interactive because they are called with -c, disregarding if th

Re: .bashrc is sourced even for non-interactive shells (when run from sshd)

Pierre Gaston wrote: On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote: On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston wrote: On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote: bash sources .bashrc even for some non-interactive shells. ... "Remote non login non interactive shells" Bash h

req for fix: Completion: inconsistent case correction and '/' appending(for dirs)

if I type in a path: (1st example) > ls -d /share/doc/new, bash displays: ls /share/doc/New\ Folder Pressing 'Enter' gets: ls: cannot access /share/doc/New Folder: No such file or directory vs. (2nd example) > ls /share/do ls /share/Doc/n ls /share/Doc/New\ Folder/ () /share/Doc/New Folder/

Re: Possible bug: Race condition when calling external commands during trap handling

Andreas Schwab wrote: A trap is not a signal. It doesn't "come in". A trap handler is executed because some condition is true at a command boundary. Andreas. That still begs the question... If you are in your trap handler, and you don't reset the signal -- how can you guarantee that you

Re: locale specific ordering in EN_US -- why is a

Eric Blake wrote: They still don't make any sense in any locale except C, because POSIX no longer requires collating order. The regex(7) man page says that [xx-xx] uses ***collating order**:: The regex(7) man page _of which system_? Just because _some_ systems (like glibc, picking the POS

Re: locale specific ordering in EN_US -- why is a

Eric Blake wrote: On 05/21/2012 05:42 PM, Linda Walsh wrote: Only in POSIX 1992 or in the C locale. In POSIX 2001 and POSIX 2008, and non-C locales, [A-Z] is explicitly undefined, == ONLY under POSIX... You may not believe this, but there are other standards than POSIX

Re: Possible bug: Race condition when calling external commands during trap handling

Andreas Schwab wrote: Bob Proulx writes: And lastly I will comment that you are doing quite a bit inside of an interrupt routine. Typically in a C program it is not safe to perform any operation that may call malloc() within an interupt service routine since malloc isn't reentrant. Bash i

Re: locale specific ordering in EN_US -- why is a

Eric Blake wrote: On 05/21/2012 03:02 PM, Linda Walsh wrote: the cat was out of the bag. POSIX 2001 had to continue to allow existing implementations, by stating that range expressions in anything but the C locale are explicitly undefined. - Explicitly undefined

Re: locale specific ordering in EN_US -- why is a

Eric Blake wrote: On 05/21/2012 01:51 PM, Linda Walsh wrote: POSIX is not supposed to be prescriptive -- but **descriptive**... I can't think of anywhere that a-z or A-Z would have included letters from the opposite case... so how did POSIX come to *prescribe* that this be the

Re: locale specific ordering in EN_US -- why is a

Aharon Robbins wrote: You'd think unicode would have something to say about collation order that wouldn't allow such randomness, but maybe not. It actually makes sense that it doesn't, since Unicode is more or less a mapping of code points to glyphs, which is language independant. The rules

Re: locale specific ordering in EN_US -- why is a

Chet Ramey wrote: On 5/21/12 3:37 PM, Linda Walsh wrote: This is a prime example of Posix being stupid and bad for computer science. They take a deterministic behavior and define it to be non-deterministic and break 1000's of programs. Try being a little less English-ce

Re: locale specific ordering in EN_US -- why is a

Greg Wooledge wrote: On Mon, May 21, 2012 at 12:19:26PM -0700, Linda Walsh wrote: Greg Wooledge wrote: For instance, on HP-UX 10.20, in the en_US.iso88591 locale: A a ... B b Meanwhile, on Debian 6.0, in the en_US.iso88591 locale: a A ... b B So which is correct? Both

Re: locale specific ordering in EN_US -- why is a

Greg Wooledge wrote: On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote: For instance, on HP-UX 10.20, in the en_US.iso88591 locale: A a ... B b Meanwhile, on Debian 6.0, in the en_US.iso88591 locale: a A ... b B As you can see, the two en_US.iso88591

locale specific ordering in EN_US -- why is a

As the perl folks are about to release another version with yet more major unicode corrections (apparently they have had to redo alot of namespace and unicode stuff in every major version since 5.6 due to the changing of the guard (amongst other reasons). But perl has the ability in the ne

Re: Parallelism a la make -j / GNU parallel

Ole Tange wrote: On Sat, May 12, 2012 at 9:34 AM, Linda Walsh wrote: Ole Tange wrote: Can you explain how that idea would differ from sem (Part of GNU Parallel)? � � � �Because gnu parallel is written in perl? �And well, writing it in perl that's near easy... did that about ... 8

Re: Parallelism a la make -j / GNU parallel

Ole Tange wrote: Can you explain how that idea would differ from sem (Part of GNU Parallel)? Because gnu parallel is written in perl? And well, writing it in perl that's near easy... did that about ... 8 years ago? in perl... to encode albums in FLAC or LAME -- about 35-45

Re: Severe Bash Bug with Arrays

no need to convince someone with your views of anything. Maarten Billemont wrote: On 26 Apr 2012, at 01:18, Linda Walsh wrote: Ishtar:> echo "${b[*]}" Please note that expanding array elements using [*] is usually NOT what anyone wants. I didn't say never to use &qu

Re: Is it possible or RFE to expand ranges of *arrays*

Maarten Billemont wrote: On 26 Apr 2012, at 06:30, John Kearney wrote: Am 26.04.2012 06:26, schrieb Linda Walsh: I know I can get a="abcdef" echo "${a[2:4]}" = cde how do I do: typeset -a a=(apple berry cherry date); then get: echo ${a[1:2]} = "berry" &q

no-empty-command-line-completion -- thought fixed in 4.2? when?

I thought this was fixed in 4.2, yet I'm still seeing it... when's this going to be fixed? It's driving me crazy, as bash drops input because it asks questions about displaying 1000's of completions...). when I paste a few lines of source in at the shell -- doesn't matter if it is bash script

(yet more OT) was (Re: reply style (OT))

p.s. - the previous was yet, another example of tailoring a response to a specific situation (in case that wasn't obvious); I think it's a first for me to deliberately use someone else's addr to send such a response. my apologies to any who were offended.

Re: Severe Bash Bug with Arrays

Greg Wooledge wrote: NEVER use eval plus a brace expansion to generate a list. That's just freakin' evil. And unsafe: === But I _like_ evil sometimes! >:-> imadev:~$ a=(lib tmp bin share '`date`') imadev:~$ (export IFS=,;eval "echo /usr/{${a[*]}}") /usr/lib /usr/tmp /usr/bin /usr/shar

Re: Severe Bash Bug with Arrays

Maarten Billemont wrote: On 26 Apr 2012, at 01:18, Linda Walsh wrote: Ishtar:> echo "${b[*]}" Please note that expanding array elements using [*] is usually NOT what anyone wants. --- It was exactly what I wanted for my example to work. Please don't suggest non-wo

Re: Is it possible or RFE to expand ranges of *arrays*

John Kearney wrote: echo ${a[@]:1:2} --- Thanks!...I couldn't believe there wasn't some way to do it, but darned if I couldn't think of it or find it for that matter... sigh. Thanks again!

Is it possible or RFE to expand ranges of *arrays*

I know I can get a="abcdef" echo "${a[2:4]}" = cde how do I do: typeset -a a=(apple berry cherry date); then get: echo ${a[1:2]} = "berry" "cherry" ( non-grouped args) I tried to do it in a function and hurt myself.

Re: Shouldn't "type" and "command" complain if there are no parameters?

Victor Engmark wrote: Re-post from : [T]hese commands print nothing and return exit code 0 if no parameters are provided. But [...] `help command` and `help type` both state that at least on

Re: Passing variables by reference conflicts with local

Clark Wang wrote: On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote: It appears that `unset' is capable of traversing down the call-stack and unsetting variables repeatedly: a=0 b=0 c=0 d=0 e=0 _unset() { unset -v b c c d d d e; } t1() { local a=1 b=1 c=1 d=1 t2 }

Re: Severe Bash Bug with Arrays

Ted Okuzumi wrote: I am writing this e-mai to report to report a bug in bash Description: Cannot redirect into an array from multiline variable Does not work: echo "$mydata" | while read line; do myarray+=( "$line" ); done Have you tried this? Ishtar:> a='this is a tes

Re: how are aliases exported?

Maarten Billemont wrote: On 16 Apr 2012, at 11:43, Linda Walsh wrote: But it won't work for files below the top level of the library directory. if I have include system/errno.shh, Source is crippled to not look in PATH. When there's a slash in the file, it stops searching PAT

Re: how are aliases exported?

Maarten Billemont wrote: On 16 Apr 2012, at 09:54, Maarten Billemont wrote: On 15 Apr 2012, at 22:52, Linda Walsh wrote: But I want the syntax include file.shh to just 'work', i.e. first time, it would call my include file, which defines the function... I'm sorry, tell m

Re: how are aliases exported?

Pierre Gaston wrote: 2) non-interactive bash Aliases are off by default. So given that you need to run something at the beginning of your new bash instance anyway, you could define your aliases in a function together with the mandatory shopt, eg: function start_aliases { shopt -s exp

Re: how are aliases exported?

Pierre Gaston wrote: On Sat, Apr 14, 2012 at 8:31 AM, Pierre Gaston <mailto:pierre.gas...@gmail.com>> wrote: On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh mailto:b...@tlinx.org>> wrote: Dennis Williamson wrote: Aliases are intended for command l

Re: inconsistency with "readonly" and scope

Andreas Schwab wrote: Maarten Billemont writes: On 15 Apr 2012, at 03:21, Chet Ramey wrote: If I declare a variable readonly at global scope, I wouldn't expect it to be overridden by some local namespace pollution. I think that's fine; in the local context, your variable has a different m

<    1   2   3   4   5   6   7   >