Re: Command substitution with null bytes generates warning

Greg Wooledge wrote: Bash has only three choices that I can think of: it can silently drop the NUL bytes behavior), it can drop ALL of the bytes and return an error, or it can drop the NUL bytes with a warning (4.4 behavior). now who is being disingenuous? It was silent not just in 4.3,

Re: Command substitution with null bytes generates warning

Eric Blake wrote: On 09/19/2016 11:58 AM, Greg Wooledge wrote: wooledg@wooledg:~$ x=$(< /proc/$$/cmdline) bash-4.4: warning: command substitution: ignored null byte in input wooledg@wooledg:~$ x=$(< /proc/$$/cmdline 2>/dev/null) wooledg@wooledg:~$ Or: $ x=$(< /proc/$$/cmdline tr

Re: change in OS defaults (was: bug in [ -f file ] test)

� wrote: Yes, the can be overridden in /etc/sysctl.d. But I am going to modify the troublesome scripts in the $50k software and leave the security of the OS intact. Thanks. Actually, setting them to "1", is not "leaving the OS security intact" -- it's adding new, non-default security

Re: Mulit-line aliases and PROMPT_COMMAND

Dan Douglas wrote: The 4.4 changes will make aliases even more interesting. --- Oh? Why is that? I.e. what's happening to aliases that will make them more "interesting"? BTW, are you using "interesting" in the same way as the saying "May you live in interesting times"?

Re: IGNOREEOF and POSIXLY_CORRECT don't ignore invisible vars

Grisha Levit wrote: The manual references these values being set, not just declared, so maybe should check for invisible_p? --- Why? I.e. what were you wanting to happen? Noticeable for example because this works: $ set +o posix; f() { local POSIXLY_CORRECT=; shopt -p -o posix; }; f;

Re: [minor] "precision" of $SECONDS

Stephane Chazelas wrote: 2016-02-25 03:03:41 -0800, Linda Walsh: Stephane Chazelas wrote: $ time bash -c 'while ((SECONDS < 1)); do :; done' bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu 0.387 total Sorry I took "cp

Re: [minor] "precision" of $SECONDS

Stephane Chazelas wrote: $ time bash -c 'while ((SECONDS < 1)); do :; done' bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu 0.387 total That can take in between 0 and 1 seconds. Or in other words, $SECONDS becomes 1 in between 0 and 1 second after the shell was

Re: Q: what is a fast way to see if an 'item' is present in an array?

Greg Wooledge wrote: On Mon, Feb 15, 2016 at 07:59:21PM -0800, Linda Walsh wrote: Obviously, If I could precook the array into a hash, I'd think it would be faster... but the "cooking part", I think, is the high overhead part. Redesign the entire script so th

Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

Dan Douglas wrote: Ah so `arr+=([a]=x [b]=y)` will no longer be the same as `arr+=([a]+=x [b]+=y)`? I never liked that for associative arrays because the only workaround was to do multiple arr[key]= assignments to update or add more than one element at a time. My thinking was that this is due

Q: what is a fast way to see if an 'item' is present in an array?

I has a little 4 line func that returns true or false if a string was in an array I came up with a different way of doing it, that I though might be faster... but... putting them in a file and running loops on them. (times below). Obviously, my feeling for what might be faster was way wrong.

Re: inconsistent function of "-v" use w/arrays and hashes

Linda Walsh wrote: I seem to remember some discussion of this before -- not being able to use -v to check if a hash was defined, but having it "work"(?) w/arrays? So instead of "-v" on an array/hash name only looking at the value of [0] (for either), can it be enhanc

Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

Chet Ramey wrote: On 2/15/16 12:35 PM, Linda Walsh wrote: Bash Version: 4.3 Patch Level: 42 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] When I create hash and later add keys using the form "HASH+=([key]=

Re: 'bashbug behavior and doc problem(s)...

Greg Wooledge wrote: On Mon, Feb 15, 2016 at 10:31:24AM -0800, LA Walsh wrote: Ended up looking at manpage, where it says under "ENVIRONMENT": EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug defaults to emacs. This is not correct (probably it used to

bug adding K,V pairs to existing hash with HASH+=([K]=V)

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu'

inconsistent function of "-v" use w/arrays and hashes

I seem to remember some discussion of this before -- not being able to use -v to check if a hash was defined, but having it "work"(?) w/arrays? I think, though, the fact that it operates inconsistently makes it a bug. I.e. if always work or fail, at least it is behaving consistently, feels

Re: bash source question & suggestion?

Chet Ramey wrote: On 2/9/16 7:30 PM, Linda Walsh wrote: At various times I see people contributing code to bash. I was wondering if it might be possible to use C++ in some patches or new files? I'm not opposed to looking at new functionality that uses C++, but I would prefer

Re: bug when 'cd ..' to a directory who's parent has been deleted

Andreas Schwab wrote: Linda Walsh <b...@tlinx.org> writes: You can't open a file handle on a file. The fd comes from some OS call associating it with the file on disk (or some other conn

bash source question & suggestion?

At various times I see people contributing code to bash. I was wondering if it might be possible to use C++ in some patches or new files? I know that the kernel, and the glib include files go to extra pain to declare 'C' functions when using C++ where those C function need to be called from

Re: bug when 'cd ..' to a directory who's parent has been deleted

Chet Ramey wrote: On 2/8/16 9:59 AM, Andreas Schwab wrote: Chet Ramey writes: `cd ..' should fail, since the parent no longer exists, and the pathname canonicalization should fail, since there's presumably no longer a valid path to reach the current directory.

manpage question re: '--debugger': what/where is debugger *profile*

Under the bash-arg "--debugger" it says: Arrange for the debugger profile to be executed before the shell starts. Turns on extended debugging mode (see the description of the extdebug option to the shopt builtin below). When I think of a "profile" in bash, I think of things

Re: bug when 'cd ..' to a directory who's parent has been deleted

Dave Rutherford wrote: On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh <b...@tlinx.org <mailto:b...@tlinx.org>> wrote: >> Why would that be more reasonable than anything else? It references a >> path that doesn't exist. > Um...Not exactly. As long as there's a

capturing in ${VAR//(*(\/)(+([^\/]))?(\/)/_${BASH_REMATCH[1]}_}

When you are doing a var expansion using the replacement format ${VAR//./.}, is there some way to put parens around some part of the expression and reference them as in the [[V~re]] RE-matches? Couldn't find anything in the manpage, but I could easily have missed something...? Thanks...

Re: doesn't bash do variable subst. or quote removal on function statement

Chet Ramey wrote: On 1/12/16 4:33 PM, Linda Walsh wrote: --- But why? It's less noisy than any alternative. It's not as if I can type echo $(1+2) and expect it to work. Because it only ever appeared in a Posix draft standard, and there's no reason not to use the standard syntax

Re: doesn't bash do variable subst. or quote removal on function statement

Greg Wooledge wrote: On Tue, Jan 12, 2016 at 11:52:47AM -0800, Linda Walsh wrote: Also, from a documentation standpoint, not all behaviors are documented in the manpage, like: echo $[1+2] as far as I can tell, isn't documented, yet not supporting its behavior would break many older

Re: doesn't bash do variable subst. or quote removal on function statement

Chet Ramey wrote: No. The shell doesn't perform any word expansions on the `name' when executing a function definition command. Since the documentation doesn't say it performs any expansions, why would you assume it does? Because it does quote quote removal on other statements that

doesn't bash do variable subst. or quote removal on function statement

Reuti wrote: Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski: hello Linda, On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh <b...@tlinx.org> wrote: For what it's worth, It might be useful to have something like 'command' [..] that would be useful, a keyword like: func

Re: aliases v. functions; command extension? (-f & -F)?

For what it's worth, It might be useful to have something like 'command' that (or maybe a flag to 'command', like "-f & -F" that would search for functions for the 'command' either before ("-f") the PATH search, or after ("-F"), for the case of the command not being found in the PATH. Reuti

'official function declaration format' doesn't work if alias defined

I had an alias referring to printf that I wanted to replace with a function. instead of using the function declarator 'function' (or my alias 'sub'), I remembered that the official way was to use: P () { ... } But then ran into problems with the alias taking precedence over the function.

Re: bash variable names do not comply w/POSIX character set rules

Eduardo A. Bustamante López wrote: This definition ( http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_230 ) states: 3.230 Name In the shell command language, a word consisting solely of underscores, digits, and alphabetics from the portable character

bash variable names do not comply w/POSIX character set rules

Under section 2.5.3, Shell Variables, it mentions: LC_CTYPE Determine the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters), which characters are defined as letters (character class alpha) and characters

Re: Installation of PDF/PS/DVI and HTML files

Mathieu Lirzin wrote: Hi, Greg Wooledge writes: On Thu, Dec 03, 2015 at 01:08:13PM +0200, Ludovic Courtès wrote: Given that the GCS suggests installing only the Info version of the manual by default (info "(standards) Standard Targets") What do you think? I think

Re: prompt with \w incl. long UTF string messes up command line

Your prompt might be too long. Your 'dir' string is awfully long... echo "$dir"|wc -c 270 --- I tried a shorter version on linux: sdir='△_ >' pre='Ishtar:/tmp/' ## prefix of my dir Ishtar:/tmp/△> 012345678901234567890123456 -bash: 012345678901234567890123456: command

Upgrading shell vars to allow for possibility of FD redirection into a var.

konsolebox wrote: On Thu, Nov 19, 2015 at 4:29 AM, Linda Walsh <b...@tlinx.org> wrote: However one cannot categorically say that a NUL byte can't be used as an argument. Likely only in an escaped format, or just as a single byte or character. Solving other places where it doesn'

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Greg Wooledge wrote: On Sun, Nov 15, 2015 at 05:26:26AM -0800, Linda Walsh wrote: This can be used to serialize an array into a file and to read it back: printf '%s\0' "${array[@]}" > file So just like you can have [<>|]&[-0-9][0-0] as redirection o

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

konsolebox wrote: On Fri, Nov 13, 2015 at 8:45 AM, Linda Walsh <b...@tlinx.org> wrote: I'd like to be able to record stdout and stderr without using any temp files into bash array files, AND record the status of the command executed. You can use coproc processes that would act as b

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Greg Wooledge wrote: You should stop using irrelevant examples, and return to your core question. I believe your initial goal was to run a command, and capture the command's stdout in one variable, and the command's stderr in another variable, without using any temp files.

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Greg Wooledge wrote: On Wed, Nov 18, 2015 at 10:46:57AM -0800, Linda Walsh wrote: One thing that seems to be another problem. Greg called my attention to another printf format bug: %q causes printf to output the corresponding argument

Re: redirecting a file descriptor to an array variable? Possible? How? RFE?

Greg Wooledge wrote: On Thu, Nov 12, 2015 at 04:45:49PM -0800, Linda Walsh wrote: I'm coming up with a null-record in my brain when I think about this: I'd like to be able to record stdout and stderr without using any temp files into bash array files, AND record the status of the command

redirecting a file descriptor to an array variable? Possible? How? RFE?

I'm coming up with a null-record in my brain when I think about this: I'd like to be able to record stdout and stderr without using any temp files into bash array files, AND record the status of the command executed. Something along the lines of Array stderr=() stdout=() runprog () {

Dynamic variable failure & equiv-const strings compare unequal

Greg Wooledge wrote: Also I think you are completely misrepresenting the dynamic variable scope system that bash uses. Variables are not just global or local. There's an entire stack of them. When you reference a variable (let's say i) inside a function, bash searches up through the

Re: Dynamic variable failure & equiv-const strings compare unequal

Oleg Popov wrote: On Thu, Oct 22, 2015 at 03:01:06AM -0700, Linda Walsh wrote: [cut] I.e. test output was: Case 2 got/Expected: "222" "1\ 222\ .3\ .4" [cut] You didn't initialize the array. By the time you do "parts[1]=222" it's still empty. And in y

Re: Dynamic variable failure & equiv-const strings compare unequal

Oleg Popov wrote: $(...) is a subshell. Variables cannot be passed back from a subshell, no matter how and where they are declared. --- Um... oh.. in testor, still calling that way. I missed that. This is even more annoying for passing back results than I thought. Grrr.

Re: language inconsistency(wart) & RFE

Greg Wooledge wrote: On Sat, Oct 17, 2015 at 08:55:31AM -0700, Linda Walsh wrote: If I needed a way to declare something global, yes... But what I am wanting is a way to allow changing the defaults of the implicit variable creation (which could still be explicitly declared with &qu

Re: language inconsistency(wart) & RFE

Greg Wooledge wrote: --- please note locations of 'auto_local' # at beginning shopt -s auto_local # Pick unbiased random number from 0 to N-1 ($1 = N) # Returns value in variable r. rand() { shopt -u auto_local local max=$((32768 / $1 * $1)) while (( (r=$RANDOM) >= max )); do :; done

Re: language inconsistency(wart) & RFE

Here is an example of what I consider to be strange and/or inconsistent behavior ( tests 2 & 3 fail). test 3's failure is a real puzzler: - #!/bin/bash shopt -s expand_aliases ; alias my=declare alias array='my -a' int='my -i' dmp () { printf "%q\n" "${*:?}" ; } ip=10.20.30.40 array

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

Bob Proulx wrote: Linda Walsh wrote: Where does the OS claim it is a file descriptor? --- 1) in the kernel documentation: file 'devices.txt: /dev/fd /proc/self/fd symbolicFile descriptors 2) ls -Ll shows the type of what the symlink points to: ls -Ll /dev/fd/ total 0

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

Greg Wooledge wrote: On Sat, Oct 17, 2015 at 05:43:15PM -0700, Linda Walsh wrote: Chet Ramey wrote: I think you're missing that process substitution is a word expansion that is defined to expand to a filename. - ??? I've never seen a usage where it expands to a filename

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

Chet Ramey wrote: On 10/16/15 7:52 PM, Linda Walsh wrote: As I mentioned, my initial take on implementation was using standard pipes instead of named pipes (not having read or perhaps having glossed over the 'named pipes' aspect). I think you're missing that process substitution is a word

Re: language inconsistency(wart) & RFE

isabella parakiss wrote: Maybe you can just use this?alias declare='declare -g' If I needed a way to declare something global, yes... But what I am wanting is a way to allow changing the defaults of the implicit variable creation (which could still be explicitly declared

language inconsistency(wart) & RFE

Ok, thinking this from a different way. shopt -s implicit_vars_local or shopt -s localize_func_implicit_vars whatever... Right now, in a function, you *can* use local in a function to make a local var. Thing is, both 'declare' and 'typeset' also make a *local* var in a function, unless the

Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

In another note about different implementations associated with the pattern "[read[array]] LVALUE [< $(]+ RVALUE [)]?"... I gave a rough syntax for how I initially thought process substitution might have been implemented before I got that it used named pipes (like /dev/fd/99, for example).

Re: updating shopt compat settings to include current version

Mike Frysinger wrote: with bash-4.0, new compat options were introduced: shopt -s compat32 and with bash-4.3, a variable was added: export BASH_COMPAT=3.2 shopt -p|grep compat43 # (no output) --- Maybe if you could check if there is a compat

Running procs in bg, +Ctl-C, then Ctl-C again after they complete + NL==?

Was just playing around seeing how the sigint being ignored in children acted. wrote short function: This behavior seems limited to testing this as a foregnd function, not a shell script. I.e, sourcing the function, then execute the function: lnch function lnch { set -o monitor #

my confusion on various I/O redirections syntaxes and indirect methods

Chet Ramey wrote: On 10/12/15 7:39 PM, Linda Walsh wrote: Does it also use a tmp file and use process-substitution, or is that only when parens are present? Here-documents and here-strings use temporary files and open them as the standard input (or specified file descriptor) for the command

Re: ! in PS1 in posix mode

Chet Ramey wrote: On 10/11/15 1:37 AM, isabella parakiss wrote: In posix mode, bash replaces ! in my PS1 with the history number. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03 "The shell shall replace each instance of the character '!' in PS1 with

Re: read and env variables + POSIX => SEGFAULT

(Cc: Chet Ramey... forgot to send it to list...oop) Chet Ramey wrote: On 10/10/15 11:01 PM, Linda Walsh wrote: a= read a <<< x;echo $? 0 declare -p a declare -- a="x" # the manpage claims "one line is read from [the input], and the result # is split by wo

Re: ! in PS1 in posix mode

Chet Ramey wrote: On 10/12/15 12:28 PM, Linda Walsh wrote: Chet Ramey wrote: On 10/11/15 1:37 AM, isabella parakiss wrote: In posix mode, bash replaces ! in my PS1 with the history number. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03 "The

Re: posix handling of mapfile: SEGFAULT

Chet Ramey wrote: Thanks for the report. I fixed this, and the fix is in the devel branch. `mapfile' only takes a single variable name argument, and ignores others. This is identical to the first example. --- I see... but it pointed out that declare doesn't actually die until it

Re: ! in PS1 in posix mode

Chet Ramey wrote: On 10/12/15 7:02 PM, Linda Walsh wrote: It happens in posix mode. --- How lame! It's a '!' in a quoted string. Another example of posix braindeath -- how long before people realize that the thing branded 'posix' now isn't the real posix that was started to *describe

Re: read and env variables + POSIX => SEGFAULT

Geir Hauge wrote: On Sat, Oct 10, 2015 at 08:01:05PM -0700, Linda Walsh wrote: # this is odd: 2vars with content for 2: unset a b a= b= read a b <<< x y declare -p a b declare -- a="x" declare -- b="" # -- where did "y" go? read a b <<<

posix handling of mapfile: SEGFAULT

This was in the 2nd half of the note in the read+POSIX=>SEGFAULT, but think it got missed by focus on the 1st part. # I was doing some syntax testing and decided to try posix mode # (as it disallows various vague or unclear constructs) # in the working cases yielded the same results, but # in 2

Re: Want way to run background processes with SIGINT unignored

Chet Ramey wrote: On 10/10/15 4:19 PM, Linda Walsh wrote: Chet Ramey wrote: On 10/9/15 2:42 PM, Ian Jackson wrote: However, it would be very easy for bash to provide an option (via `set -o' perhaps) to disable this behaviour. That is, to allow SIGINT to be delivered normally to child

Re: read and env variables + POSIX => SEGFAULT

isabella parakiss wrote: $ a= read a <<< x # this creates a variable in the current shell $ declare -p a declare -- a="x" $ b= mapfile b <<< x# this doesn't $ declare -p b bash: declare: b: not found Very good point... more interesting is adding posix mode to the mix:

Re: Want way to run background processes with SIGINT unignored

Chet Ramey wrote: On 10/9/15 2:42 PM, Ian Jackson wrote: However, it would be very easy for bash to provide an option (via `set -o' perhaps) to disable this behaviour. That is, to allow SIGINT to be delivered normally to child processes. I'm restricting non-standard options to `shopt' to

bad handling of error conditions in "type -P'

I've run across several problems with how type -P returns errors. 1) if a file isn't executable, type returns it anyway in ls -l /sbin/scat -r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat type -P scat /sbin/scat 2) if a file is inaccessible, type still returns it an

bad handling of error conditions in "type -P'

There are several problems with how type -P returns errors. 1) if a file isn't executable, type returns it anyway in ls -l /sbin/scat -r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat type -P scat /sbin/scat 2) if a file is inaccessible, type still returns it an answer

Re: minor language RFE(s)

Chet Ramey wrote: These change the syntax of the shell in incompatible ways. --- I think I had the feeling of ensuring compatibility as being important and changing things in incompatible ways . "That's not easily changed w/o potential chaos..." The arithetic `for' command takes arithmetic

minor language RFE(s)

If I am using a var as an index in a for loop as in: for((i=0; i<10; ++i)); do : done or 2) as an iterator as in for i in {1..10}; do : done **and** such usage is in a function, the default is to promote 'i' to 'global' status, which is usually not needed nor desired (that doesn't

indirection on '$1, $2...' ?

Is it documented that ${!1} won't give you indirection of "$1"? I guess I missed that, and sorta expected it to do indirection the same as any other var, but doesn't seem to work in 4.3.39. Should it? Or why shouldn't it? tnx... -l

Re: indirection on '$1, $2...' ?

other problem)... sorry for line noise. Linda Walsh wrote: Is it documented that ${!1} won't give you indirection of "$1"? I guess I missed that, and sorta expected it to do indirection the same as any other var, but doesn't seem to work in 4.3.39. Should it? Or why shouldn't it? tnx... -l

Re: remaking bash, trying static, glibc refuses static...?

I sent this in response about 12 hours ago but haven't seen it come though on the list, so thought I'd resend it. Original Message Subject: Re: remaking bash, trying static, glibc refuses static...? Date: Wed, 19 Aug 2015 14:55:24 -0700 From: Linda Walsh To: bug-bash@gnu.org

Re: -e does not take effects in subshell

Chet Ramey wrote: The earlier spec had -e only exit a script if a *simple* (external) command failed. It didn't include builtins nor functions. This is not; builtins and functions are simple commands. --- The builtins are _complex_ binary blobs that replace external commands. Functions

Re: remaking bash, trying static, glibc refuses static...?

Mike Frysinger wrote: On 18 Aug 2015 21:41, Linda Walsh wrote: Mike Frysinger wrote: On 18 Aug 2015 13:34, Linda Walsh wrote: (2) it's using the nss system which lets people drop modules into the system at anytime and change the overall lookups to use that. statically linking a specific

Re: -e does not take effects in subshell

Greg Wooledge wrote: (Wow, how did we get here from -e does not take effects in subshell?) --- because the POSIX spec changed and bash's handling of -e changed to follow the new spec. The earlier spec had -e only exit a script if a *simple* (external) command failed. It didn't include

Re: -e does not take effects in subshell

Andreas Schwab wrote: Linda Walsh b...@tlinx.org writes: Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the -x switch like 'find, cp, mv, et al.) no longer works to clean out a directory stay on *one* file system. Now rm will delete things on any number of file systems

Re: remaking bash, trying static, glibc refuses static...?

Mike Frysinger wrote: On 18 Aug 2015 13:34, Linda Walsh wrote: Then can you give any technical reason why a static lib that uses no network services (i.e. running on a mini-root ) couldn't be made available for the various calls that currently claim dynamic library support is necessary. (1

Re: remaking bash, trying static, glibc refuses static...?

Mike Frysinger wrote: it is not political, nor is it related to bash at all -mike Then can you give any technical reason why a static lib that uses no network services (i.e. running on a mini-root ) couldn't be made available for the various calls that currently claim dynamic library support

Re: -e does not take effects in subshell

Eric Blake wrote: Like it or not, it is the historical behavior standardized by POSIX. This is not true. POSIX no longer documents historical behavior, but now dictates new, historically-incompatible behaviors for a variety of features in a variety of products (not just BASH). As such,

Re: -e does not take effects in subshell

Greg Wooledge wrote: On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote: Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the -x switch like 'find, cp, mv, et al.) no longer works to clean out a directory stay on *one* file system. When did POSIX or any historical

Re: why is 'direxpand' converting relative paths to absolute?

Clark Wang wrote: I had the same problem months ago. See Chet's answer: http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00069.html === Yep though I'm not sure about the reasoning in providing different behaviors based on default-dir-expansion == convert all relative paths to

Re: bash expanding relative paths in auto-complete

Andreas Schwab wrote: Linda Walsh b...@tlinx.org writes: in bash 4.3.39, if I type a command, (like .(source)) and a relative path like : ../confcomplete, it expands the relative pathname to absolute pathnames. Worksforme. Make sure to run complete -r first. --- You didn't say what

remaking bash, trying static, glibc refuses static...?

bash-4.3/lib/readline/complete.c:2193: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Other syms: getpwnam, setpwent, endpwent. Is providing a static lib that reads the local machine's /etc/passwd

why is 'direxpand' converting relative paths to absolute?

path conversion was built into it? Linda Walsh wrote: Andreas Schwab wrote: Linda Walsh b...@tlinx.org writes: in bash 4.3.39, if I type a command, (like .(source)) and a relative path like : ../confcomplete, it expands the relative pathname to absolute pathnames. Worksforme. Make sure

Re: bash expanding relative paths in auto-complete

Andreas Schwab wrote: Linda Walsh b...@tlinx.org writes: in bash 4.3.39, if I type a command, (like .(source)) and a relative path like : ../confcomplete, it expands the relative pathname to absolute pathnames. Worksforme. Make sure to run complete -r first. --- Nope -- didn't change

bash expanding relative paths in auto-complete

in bash 4.3.39, if I type a command, (like .(source)) and a relative path like : ../confcomplete, it expands the relative pathname to absolute pathnames. This is bad .. since I reuse relative commands in different absolute places. It didn't used to do this, and it's a potential security

Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)

Greg Wooledge wrote: On Sun, Aug 02, 2015 at 01:30:14PM -0700, Linda Walsh wrote: isatty () { test -c /proc/self/fd/1 ; } This can be done portably with test -t 1 if you want the body of the function to do what the name implies. (Testing for a character device gives false positives

Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)

Charles Daffern wrote: On 02/08/15 20:30, Linda Walsh wrote: if [[ $(printf \n) == $'\n' ]]; then echo T; else echo F; fi F The command substitution operators ($(...) and `...`) strip all trailing linefeeds. You are left with an empty string here. The usual workarounds I see (where

Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)

also noticed this similar strange behavior: used 'ord'** for this test (trying to compare decimal val of chars) isatty () { test -c /proc/self/fd/1 ; } ord () { local nl=; isatty nl=\n; printf %d$nl '$1 ; } ord $(printf \n) 0 ord $(printf \t) 9 ord $(printf ) 32 ord $(printf \r) 13

BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)

printf \n |hexdump -C 0a printf %s $'\n'|hexdump -C 0a if [[ $(printf \n) == $'\n' ]]; then echo T; else echo F; fi F just noticed the problem doesn't happen if I try to use '\t' (tab) printf \t |hexdump -C 09 printf %s

REGRESSION: signal handlers not running in real-time

I decided to give 4.3 a try again and ended up writing a 100 line script to take the version# as input and auto-apply all the patches in the patch dir. ARG going down a rathole... oh well. I think I got a build pretty much as I want it -- w/everything builtin statically except for a few

Re: auto-complete going on a diagonal -- set print-completions-horizontally on = equals diagonally

Chet Ramey wrote: On 7/14/15 7:49 PM, Linda Walsh wrote: --- Yeah, figures it would work right in the BASH dir... BUT... Ishtar:tools/bash/bash-4.3 cd /suse132 --- both of the below print diagonally because they have no line endings. I can't reproduce any of this on SUSE 13. What does

auto-complete going on a diagonal -- set print-completions-horizontally on = equals diagonally

When I go for auto complete now, the filenames no longer line up: Ishtar:/suse132 ls e17- e17-0.17.6-2.1.10.x86_64.rpm e17-branding-openSUSE-0.1-10.1. 2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm e17-devel-0.1 7.6-2.1.10.x86_64.rpm

Re: Is this right? test -v $hash{defined_value} == false?

Chet Ramey wrote: On 7/12/15 11:58 PM, Linda Walsh wrote: set -A hash This is an error --- a brain-o -- at least I got the capitalized-A ;-) (original code probably had a hash hash or map hash ) declare -A hash... (I rarely type out the full command due to my aliases

Re: auto-complete going on a diagonal -- set print-completions-horizontally on = equals diagonally

Chet Ramey wrote: Am still on 4.2, but in the bashdir, I get: reset ... ^L Erase is control-H (^H). Kill is control-X (^X). Ishtar:law hhsfshsdfhl^C Ishtar:law bind Ishtar:law cd ../tools/bash/bash-4.3 Ishtar:tools/bash/bash-4.3 ls bcomplete bash*bashintl.h bashversion*

Is this right? test -v $hash{defined_value} == false?

set -A hash hash=([defined_value]=22) echo ${hash[defined_value]} 22 [[ -v ${hash[defined_value]} ]] echo pass [[ -v ${hash[defined_value]} ]] || echo fail fail [[ -v {hash[defined_value]} ]] || echo fail fail [[ -v hash[defined_value] ]] || echo fail fail [[ -v

Re: eval a=b\ c

d...@yost.com 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'

Re: eval a=b\ c

Dennis Williamson wrote: I'm trying to put a command in a variable, but the complex cases always fail! : http://mywiki.wooledge.org/BashFAQ/050 Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048 Dunno, but I see nothing on that page about using printf -v %q or

Re: [Help-bash] make function local

Greg Wooledge wrote: AFAIK, _exec_gvim, can only be called from within function gvim, no? That is not correct. In bash, all function definitions are global. imadev:~$ f1() { f2() { echo I'm f2; }; }; f1; f2 I'm f2 You left out a few important parts, like f2 being called inside f1

Re: [Help-bash] make function local

Eduardo A. Bustamante López wrote: On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote: [...] AFAIK, _exec_gvim, can only be called from within function gvim, no? No. Doing this: outerfunc() { func() { ...; } func args unset -f func } outerfunc Doesn't guarantee that `func

Re: [Help-bash] make function local

Greg Wooledge wrote: The problem is, ALL function definitions (and un-definitions) are global. --- yeah... If there was a func defined at the global scope, you've obliterated it. I don't understand why you don't understand this. --- I don't understand why you think I don't

  1   2   3   4   5   6   >