Re: consistency probs w/ 'readonly -f' & 'export -f

On Thu, Jun 08, 2017 at 03:48:21PM -0700, L A Walsh wrote: > >Second) What is the official way to list functions w/their > >flags+definitions > > in a way reusable as input? declare -fp funcname > >Third) How can one print the flags on a single function? > using> declare -pf Why are you

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 08:06:28AM +0700, Peter & Kelly Passchier wrote: > On 09/06/2560 05:26, Eduardo Bustamante wrote: > > What's wrong with: > > > > IFS= read -rd '' foo < "$file" > > I think that's the winner! So long as you know the file doesn't contain any NUL bytes. The other variants

Re: Trailing newlines disappear

On Thu, Jun 08, 2017 at 10:44:29PM +0200, Geir Hauge wrote: > You can pick one of these instead: > > mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS > > or > > mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}" or lambda() { local MAPFILE IFS=; mapfile < "$file";

Re: Trailing newlines disappear

ARGH! You dropped the list address! This was on bug-bash, right?? On Fri, Jun 09, 2017 at 03:14:10AM +0700, PePa wrote: > On 09/06/2560 02:14, Greg Wooledge wrote: > > Well, it leaves IFS changed, because you didn't revert or unset it, > > or run the entire thing in a function

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 01:52:44AM +0700, Peter & Kelly Passchier wrote: > On 09/06/2560 00:42, Greg Wooledge wrote: > > foo=$(cat "$file"; printf x) foo=${foo%x} > > The workaround I came up with is: > mapfile <"$file"; IFS= foo=${MAPFILE[@]} >

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 12:38:19AM +0700, PePa wrote: > I would think this is a bug: > 4.3.48(1)-release> printf "q\n\n\n" >w > 4.3.48(1)-release> printf "$(cat w)" > q > 4.3.48(1)-release> > > Is there some workaround to somehow preserve the trailing newlines? It's not a bug. This is how

Re: Patch for unicode in varnames...

On Tue, Jun 06, 2017 at 12:02:41PM -0700, L A Walsh wrote: > Bash *is* the linux > shell. It's being adopted elsewhere, but it seems to have first grown > in use in the linux community. Bash predates Linux. Bash was first released in 1989. Linux wasn't released until 1991. Bash is the GNU

Re: Patch for unicode in varnames...

On Tue, Jun 06, 2017 at 07:01:23AM -0700, L A Walsh wrote: > George wrote: > >On Mon, 2017-06-05 at 16:16 -0700, L A Walsh wrote: > >>George wrote: > >>>On Mon, 2017-06-05 at 15:59 +0700, Peter & Kelly Passchier wrote: > On 05/06/2560 15:52, George wrote: > >there's not a reliable

Re: RFE: Please allow unicode ID chars in identifiers

On Sun, Jun 04, 2017 at 09:20:45AM +0700, Peter & Kelly Passchier wrote: > On 04/06/2560 04:48, L A Walsh wrote: > >> Greg Wooledge wrote: > >>> Here is a demonstration of the cost of what you are proposing. In my > >>> mail user agent, your variable s

Re: RFE: Please allow unicode ID chars in identifiers

On Thu, Jun 01, 2017 at 09:31:24PM -0700, L A Walsh wrote: > Variable names like: > > L??v -- (3 letter word pronounced like Leave), (most recent try...) Here is a demonstration of the cost of what you are proposing. In my mail user agent, your variable shows up as L??v. Source code with your

Re: Infinite loop in bash glob matching

On Thu, May 18, 2017 at 08:29:13AM +0200, Zoltán Herczeg wrote: > I think throwing an error would be better than an undefined behaviour. Bash > throws error for solo parenthesis, a similar technique could be used here. That's not really an option, because an unmatched [ isn't a syntax error.

Re: unalias works weirdly inside an if-then block

On Fri, May 12, 2017 at 02:33:06PM +0200, Gabor Burjan wrote: > unalias works weirdly inside an if-then block Because bash has to parse the entire compound command (the entire multi-line command up to "fi") before it can begin execution of it. > alias cp='cp -i' > > if [[ 1 = 1 ]]; then >

Re: bash-4.2.53: HISTSIZE=-1 causes segfault on startup

On Mon, May 08, 2017 at 07:43:27PM -0400, Chet Ramey wrote: > If you want a workaround that should work in bash-4.2 and bash-4.3, try > using some large number (people have used ) for HISTSIZE, giving you > effectively unlimited history. Or check $BASH_VERSION (or ${BASH_VERSINFO[@]}) before

Re: No such file..?

On Fri, May 05, 2017 at 10:57:34AM +0700, Peter Passchier wrote: > $ /home/pp/bin/caddy --version > -bash: /home/pp/bin/caddy: No such file or directory > > $ file /home/pp/bin/caddy > /home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked, interpreter

Re: Bash is incorrectly and inconsistently expanding tilde in $PATH

On Thu, May 04, 2017 at 09:54:07AM -0500, Eduardo Bustamante wrote: > Also, I think it's a bit of a stretch to call this a security problem. > The scenario you describe (a user having a directory literally named > `~' with a bin subdirectory, a malicious program creating evil > binaries in

Re: Bash -f Test Operator - Not working as expected

On Mon, May 01, 2017 at 11:24:44PM -0500, Eduardo Bustamante wrote: > > For the behavior you want, you need something like: > > > > test ! -h "$pathname" -a -f "$pathname" Don't use that. test ! -h "$pathname" && test -f "$pathname" would be safe. Your test command has 6 arguments, for which

Re: Clarification - Space removal in AE takes place before brace expansion

On Mon, May 01, 2017 at 04:37:10PM +0200, Florian Mayer wrote: > $ "{1..10}'+' 0" > actually is seen as > $ "{1..10}'+ 0'" # postabmle = '+0' > Then, it expands that to > '1+ 0 2+ 0 3+ 0 4+ 0 5+ 0 6+ 0 7+ 0 8+ 0 9+ 0 10+ 0' > and evaluates it arithmetically resulting in 55. No, and no. I think

Re: Clarification - Space removal in AE takes place before brace expansion

On Mon, May 01, 2017 at 03:49:39PM +0200, Florian Mayer wrote: > However, > $ (({1..10}'+' +0)) > Gives me "bash: ((: 1+ +0 2+ +0 3+ +0 4+ +0 5+ +0 6+ +0 7+ +0 8+ +0 9+ > +0 10+ +0: syntax" > which is the same thing I'd get, when I whould've done {1..10}'+ +0'. Thus > in this same arithmetic

Re: Space removal in AE takes place before brace expansion

On Mon, May 01, 2017 at 03:29:43PM +0200, Florian Mayer wrote: > > sum=0; for ((i=1; i<=10; i++)); do ((sum+=i)); done > You can actually omit ???sum=0;???, because bash dereferences unset variables > to 0 > (according to the holy manual of course). Not if the user running the script exported

Re: Space removal in AE takes place before brace expansion

On Sun, Apr 30, 2017 at 08:31:30PM +0200, Florian Mayer wrote: > I want to add up all numbers from 1 to 10, sum=0; for ((i=1; i<=10; i++)); do ((sum+=i)); done > but when I do > $ echo $(({1,10}???+??? +0)) # with a space between the first + and the > second one I cannot figure out what you

Re: Bash -f Test Operator - Not working as expected

On Sat, Apr 29, 2017 at 07:47:06PM -0400, Adam Danischewski wrote: > $ [[ -L > "/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3" > ]] && echo hi > hi > $ [[ -f > "/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3" > ]] && echo hi > hi > > It

Re: Syntax error near unexpected token `newline' within loops

On Mon, Apr 24, 2017 at 07:49:36AM -0500, Eduardo Bustamante wrote: > On Mon, Apr 24, 2017 at 7:44 AM, Greg Wooledge <wool...@eeg.ccf.org> wrote: > [...] > > The outer (( )) in the C-style for loop already create an arithmetic > > expression context. You don't need to use

Re: Syntax error near unexpected token `newline' within loops

On Mon, Apr 24, 2017 at 12:59:01PM +0200, wer...@suse.de wrote: > V_NAME=Friday > for (( INDEX=0; INDEX<$((10-$(expr length $V_NAME))); INDEX++ )) The outer (( )) in the C-style for loop already create an arithmetic expression context. You don't need to use $(( )) inside them. You

Re: bash 4.4 null byte warning!!

On Thu, Apr 06, 2017 at 07:47:35AM +, emlyn.j...@wipro.com wrote: > FIND_RPM=`find /opt/RPM/components -type d -name enum-1.1.6 -print0` > It throws a warning as below: > > bash: warning: command substitution: ignored null byte in input Your command is broken, and bash is warning you of

Re: Is it normal for `bash -s foo` not to make 1=foo available from ~/.bashrc?

On Wed, Mar 29, 2017 at 04:10:14PM +0200, Torka Noda wrote: > Well, sorry for the confusion, I'll stop here. I think it's > weird for Bash's positional parameters, and the whole argument > list if modified with '-s', not to be accessible from > initialization files, but `env` does what I want

Re: pipefail with SIGPIPE/EPIPE

On Thu, Mar 23, 2017 at 10:14:01PM -0700, Pádraig Brady wrote: > OK let's not derail this into a discussion specific to errexit. > Can we please improve things? > You say to not use errexit, and instead use `|| exit 1` where appropriate. > In that case can we fix this case? > > set -o pipefail

Re: pipefail with SIGPIPE/EPIPE

On Thu, Mar 23, 2017 at 07:27:19PM +, Jay Freeman (saurik) wrote: > > Errexit (a.k.a. set -e) is horrible, > > and you should not be using it in any new shell scripts you write. > > It exists solely for support of legacy scripts. > > Wow. For those of us who don't know this, what should we be

Re: pipefail with SIGPIPE/EPIPE

On Thu, Mar 23, 2017 at 08:50:45AM -0700, Pádraig Brady wrote: > I was bitten by this again when combined with set -e. > I.E. this script doesn't finish: > > #!/bin/bash > set -o errexit > set -o pipefail > yes | head -n1 > echo finished > > That makes the errexit and pipefail options decidedly

Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"

On Tue, Mar 21, 2017 at 07:32:27PM +0100, Martijn Dekker wrote: > A workaround for the original poster's problem could be: > > (unset -f jobs; unalias jobs; eval 'jobs -l') | wc > > The 'eval' is to stop the alias from being expanded at parse time before > you have a chance to unalias it.

Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"

On Tue, Mar 21, 2017 at 04:53:59PM +, Hengyang Zhao wrote: > But back to the user's perspective, as I looked up "help jobs" or "help > builtin", the sematics of "builtin" is only for forcing the shell to use > the builtin version, right? Actually, I was writing a script that needs to > secure

Re: Bash monopolizing or eating the RAM MEMORY

On Mon, Mar 20, 2017 at 03:54:37PM -0300, Noilson Caio wrote: > thank you so much Mr. Wooledge. i guess that BUG is a strong word for this > case. i fully agree about "his is not a bash bug. It's a problem with your > approach.", actuality that's my preoccupation. can you help me to > understand

Re: "unset var" pops var off variable stack instead of unsetting it

On Fri, Mar 17, 2017 at 09:51:34PM +, Stephane Chazelas wrote: > Then, the "unset", instead of unsetting IFS, actually pops a > layer off the stack. > Credits to Dan Douglas > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html) > for finding the bug. He did find a use for it

Re: unset array[0] doesn't delete the element

On Sat, Mar 04, 2017 at 09:10:00PM -0800, Isaac Good wrote: > Repeat-By: > $ arr=(1 2 3); unset arr[-1]; echo "${arr[@]}" > 1 2 3 On Sat, Mar 04, 2017 at 09:14:09PM -0800, Isaac Good wrote: > Bug report being withdrawn. I had nullglob set so unset wasn't being > invoked properly. The

Re: -eq and strings

On Sat, Mar 04, 2017 at 01:15:58PM +0100, Rob la Lau wrote: > Looking a bit further: it doesn't do any comparison on the given strings: > > $ [[ "x" -eq "y" ]] && echo "yes" || echo "no" > yes You're misunderstanding. In a math context, which you are creating here by using -eq, the word 'x' is

Re: Pipe using subshells, variables not saved

On Fri, Mar 03, 2017 at 10:04:23PM -0800, Misaki wrote: > > reason for piping: > > echo wat | for i in $(< /dev/stdin); do declare -g new="$i"; done > > > > (using find instead of echo, not sure if better way to loop) while IFS= read -r file; do blah "$file"; done < <(find . -type f) That's

Re: Problem with 'upper' class when nocaseglob

On Thu, Mar 02, 2017 at 10:57:57PM +0100, Luká?? Ba??inka wrote: > A short script or ???recipe??? which exercises the bug and may be used > to reproduce it: >$ touch a A >$ echo [[:upper:]] >A >$ shopt -s nocaseglob >$ echo [[:lower:]] >a A >$ echo [[:upper:]] >

Re: Broken Termcaps

On Wed, Mar 01, 2017 at 05:15:51PM -0500, Lfabbro wrote: > Greg, I'm not sure what you mean by termcaps are legacy... > I mean, I personally use curses.h, term.h and termios.h > aren't them termcaps? No. Those are terminfo. Be grateful. If you want a brief overview, you can start with "man

Re: Broken Termcaps

On Wed, Mar 01, 2017 at 05:02:32PM -0500, Lfabbro wrote: > > echo $PS1 > \[\033[01;32m\][\u@\h\[\033[01;37m\] \W$(__git_ps1 " > (\033[31m%s\033[37m)")\033[32m]\$\[\033[00m\] There are some unprotected escape sequences inside the $(...) but I have absolutely no idea what that command substitution

Re: Broken Termcaps

On Wed, Mar 01, 2017 at 09:48:08PM +, Eduardo Bustamante wrote: > El mié., mar. 1, 2017 3:46 PM, Eduardo Bustamante > escribió: > > Description: > > Bash rewrites on the same line if I exeed line terminal width lenght. > > > Do you have an exotic PS1 or PROMPT_COMMAND ?

Re: break no longer breaks out of loops defined in an outer context

On Wed, Mar 01, 2017 at 08:48:20AM -0800, L A Walsh wrote: > Chet Ramey wrote: > >Compatibiity options are all mutually exclusive, last one wins. > --- > But the way it is now -- if someone is using a compat option > for an earlier version, and now needs another compat option > for some other

Re: process substitution flawed by design

On Tue, Feb 21, 2017 at 03:11:22PM +0100, Florian Mayer wrote: > >What does it do? > It behaves like the p-operation on unary Sys-V semaphores. OK, without digging any further into this morass, and without trying to guess whether you've found a bug in bash or in your own tool, can I just leave

Re: process substitution flawed by design

On Tue, Feb 21, 2017 at 02:18:03PM +0100, Florian Mayer wrote: > for mutex --lock I use a tool which I wrote myself. What does it do? > The following code assumes the lock to be in state not-taken before the > snippet runs. What lock? > echo foo | tee \ > >(mutex --lock; echo before;

Re: process substitution flawed by design

On Mon, Feb 20, 2017 at 11:25:22PM +0100, Florian Mayer wrote: > echo foo | tee >(echo $$) >(echo $$) >/dev/null | cat > > returns the same PID twice. $$ is the PID of the main shell. I think what you want is the PID of each subshell, $BASHPID. imadev:~$ cat <(echo $$) <(echo $$) 3751 3751

Re: echo -n

On Thu, Feb 02, 2017 at 10:26:22PM +0530, Jyoti B Tenginakai wrote: > I have tried using the printf instead of echo. But the issue with printf > is , the behaviour is not consistent with what echo prints for all the > inputs i.e. But what echo prints is by definition inconsistent across platforms

Re: echo -n

On Thu, Feb 02, 2017 at 02:32:00PM +0530, Sangamesh Mallayya wrote: > in bash echo -n , echo -e , echo -E has a special meaning. But we do not > have a way in bash shell if we want to print > -n , -e and -E using echo command. Other shells supports printing of > -n/-e/-E options using echo

Re: history vs. poweroff

On Wed, Feb 01, 2017 at 03:31:57AM +0800, ? Dan Jacobson wrote: > GW> Log out, log back in as root, issue the command, and accept that root's > GW> (very short) shell history will be lost. > > Well mention that on the man page. > I.e., the man page should address the paradox of saving a

Re: history vs. poweroff

On Wed, Feb 01, 2017 at 03:13:45AM +0800, ? Dan Jacobson wrote: > GW> I'm confused. You don't logout before shutting down your computer? > GW> I would strongly recommend doing so, unless it's an emergency. > > All I know is I want to issue one command to turn off the computer. > If I

Re: history vs. poweroff

On Tue, Jan 31, 2017 at 10:13:46AM +0800, ? Dan Jacobson wrote: > However on slower systems, at the end of the day when the user issues > the poweroff(8) command, all this might not complete, resulting in the > entire day's of history getting thrown away. I'm confused. You don't logout

Re: What is correct syntax to check for empty array? behavior diffs between 4.3 and 4.4

On Thu, Jan 26, 2017 at 01:11:25PM -0800, L A Walsh wrote: >> Subject: Re: What is correct syntax to check for empty array? The number of elements is 0 if the array is empty. So you would test whether ${#array[@]} is 0. > > set -u # now add an undefined check Now you've

Re: nullglob make unset on array member fail ?

On Mon, Jan 23, 2017 at 03:04:40PM +0100, admn ombres wrote: > $ x=(x); echo ${#x[@]}; shopt -s nullglob; unset x[0]; echo ${#x[@]} You need to quote 'x[0]' to avoid having it globbed against files in the current working directory, regardless of whether you're using nullglob. The presence of a

Re: bash: /home/greenhornet/.bashrc: line 120: syntax error: unexpected end of file

On Mon, Jan 16, 2017 at 06:01:24PM +0100, Daniel Bullard wrote: > what do i do? First, stop top-posting. Second, stop taking list questions to private email. (I've remembered one of the list addresses to add back to the Cc: list, but not the other.) Third, add the missing "fi" line at the end.

Re: bash: /home/greenhornet/.bashrc: line 120: syntax error: unexpected end of file

On Sun, Jan 15, 2017 at 08:44:24PM +0100, Daniel Bullard wrote: > # enable programmable completion features (you don't need to enable > # this, if it's already enabled in /etc/bash.bashrc and /etc/profile > # sources /etc/bash.bashrc). > if ! shopt -oq posix; then > if [ -f

Re: suggestions: for bash shell: "shebam's and shebang's"

On Wed, Jan 11, 2017 at 01:30:02PM -0500, Bill William wrote: > The problem with the shebang is that its not a file type its an > executable...what is needed is the option to only specify a file type... > examples: > > //Example Shebang: #!/usr/bin/perl > //Example Shebam:#:utf8 >

Re: BUG??

On Thu, Dec 29, 2016 at 09:43:54PM +0700, PePa wrote: > if (((q==1)) || [[ $r ]]) && grep -q $s $file > then > echo "$s is in $file, and either q is 1 or r is not empty" > fi > > I guess this works, but it spawns a subshell. Is there a better way? What you're literally asking for should be

Re: set command overrides my ARGV array

On Tue, Dec 27, 2016 at 05:21:13PM +0100, Martin MOKREJ?? wrote: > Hi, > I wanted to enable error code reporting for piped processes. This should > be doable by "set -o pipeline on". There is no such set -o keyword. I think you're looking for "set -o pipefail" instead. (Note: there is no

Re: bug report

ar.more, I could not got > your point regarding "csh-style history expansion" but i did your kind > suggest and the same result. > many thanks for your support. > > > On Tuesday, December 20, 2016 6:17 PM, Greg Wooledge > <wool...@eeg.ccf.org> wrote

Re: bug report

On Tue, Dec 20, 2016 at 12:39:12PM +, Hossein Vatani wrote: > Hi experts,I encountered a issue that i guessed a bug.i tried to make bash > script that generate strong password and save it with htpasswd command.if i > generate er"exc'oti!ot  for password, i could not send it as string to >

Re: Change in behavior

On Tue, Dec 13, 2016 at 09:16:12AM -0600, Eduardo Bustamante wrote: > On Tue, Dec 13, 2016 at 9:08 AM, Vladimir Marek > wrote: > [...] > > $ cat configure > > set -o posix > > echo ${0.8} > > echo after > > > > $ bash a.sh > > 3.2.52(1)-release > > a.sh: line 3: ${0.8}:

Re: Problem outputting a quote in a variable expansion which is in a here doc

On Wed, Dec 07, 2016 at 12:56:00AM +, Daniel Einspanjer wrote: > echo The desired output is: > echo "var = \"test test\"" imadev:~$ q=\" imadev:~$ var="a variable" imadev:~$ cat < ${var:+var = $q$var$q} > EOF var = "a variable" imadev:~$ echo "$BASH_VERSION" 4.4.0(1)-release Putting literal

Re: Could bash do what make does?

On Mon, Dec 05, 2016 at 11:37:11PM +1100, Robert Durkacz wrote: > I am asking about shell scripting > of software builds, something that is perfectly possible to do and once > must have been the common way. Based on what evidence? Show me a shell script created to build a software project

Re: Could bash do what make does?

On Fri, Dec 02, 2016 at 10:53:30PM +1100, Robert Durkacz wrote: > really I am asking why should not program builds have been scripted with > bash all along For starters, make is *older* than bash, by over a decade. https://en.wikipedia.org/wiki/Make_%28software%29 says that make originated at

Re: [PATCH] Readline not being able to handle long lines

On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote: > > Buggy (replace the ^-sequences in the second line): > > PS1="[\${PWD##*/}]\$ " # set the prompt > > PS1="^[]0;\$PWD^G^M$PS1"# set the window title > > > > Turns out this was the only one buggy. > So it was all the (mis-)

Re: Not operator (~) fail on arithmetic expansion.

On Sun, Nov 27, 2016 at 09:54:59PM -0800, L A Walsh wrote: > Does ~ get home dirs for UID's? I thought it only worked > for usernames? imadev:~$ id uid=563(wooledg) gid=22(pgmr) groups=1002(webauth),208(opgmr) imadev:~$ echo ~563 ~563

Re: bash integer overflow (?) with large HISTFILESIZE

On Mon, Nov 14, 2016 at 08:39:27PM -0500, Patrick Donnelly wrote: > Bash Version: 4.4 > Patch Level: 0 > Release Status: release > > Description: > > With the latest version of bash just deployed in the Arch Linux > repositories, bash fails with HISTSIZE=2147483647: > > bash: xmalloc: cannot

Re: [Help-bash] How to make vi-insert mode's ctrl-w work in the 4.3 way?

On Fri, Nov 04, 2016 at 10:32:17AM -0400, Chet Ramey wrote: > On 11/4/16 6:30 AM, Clark Wang wrote: > > For example, if I have inputted the following after the prompt: > > > > # foo "abc" > > > > In bash 4.3's vi-insert mode, when I press ctrl-w it'll delete the whole > > "abc" (including

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

On Fri, Oct 21, 2016 at 09:19:08PM -0700, L. A. Walsh wrote: > Eduardo Bustamante wrote: > >what's wrong with?: > >echo ${#array[@]} > Not when "-u" is set, which I often have on to help catch misspellings. > > set -u > echo ${#array[@]} > bash: array: unbound variable See

Re: Assigning to BASHPID fails silently

On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote: > Assigning to BASHPID most certainly does have an effect. Since you > didn't quote that part, I think you might have missed my point that > attempting this will silently exit the shell without any error message, > causing the problem

Re: forked before bash subshell

On Tue, Oct 11, 2016 at 07:14:24PM -0700, s7v7nisla...@gmail.com wrote: > why bash bahavior like this? is that a bug? > > if not, why should forked before execute subshell? Because that's how subshells work. A subshell *is* a fork. > 1. the script to reproduce > bash-4.4$ cat t.sh > (cd /tmp

Re: Execution of a data string

On Wed, Sep 21, 2016 at 11:15:45PM -0400, mobatu...@yahoo.ca wrote: > In Summary: > > declare -a "$string" # results in execution of $string > declare -a a=($string)# does not result in execution of $string This is why you don't use the first form. It's the same with eval -- if you

Re: Command substitution with null bytes generates warning

On Tue, Sep 20, 2016 at 12:17:37PM -0700, L. A. Walsh wrote: > /sys/class/net/br0> /tmp/showvals > addr_assign_type: 1 > addr_len: 6 > address: 00:15:17:bf:be:b2 > /tmp/showvals: line 63: printf: `invalid format character > brforward:

Re: Command substitution with null bytes generates warning

I probably shouldn't even bother at this point, but morbid curiosity compels me to foolish ends. What are you DOING with these files that contain NUL bytes that makes it permissible to simply drop the NUL bytes on the floor, with no explicit step like tr -d \\0 to remove them? How is your script

Re: Command substitution with null bytes generates warning

On Mon, Sep 19, 2016 at 01:10:56PM -0700, L. A. Walsh wrote: > Does readarray allow specifying the nulls as line-terminators? Yes, as of bash 4.4.

Re: Command substitution with null bytes generates warning

On Mon, Sep 19, 2016 at 11:30:56AM -0700, Linda Walsh wrote: > How about, w/r/t the new warning -- I complain because the null bytes > are missing after bash knowingly detected them and illegally modified > the input. Putting out a warning about null bytes, doesn't mean it's > "ok" to drop them.

Re: Command substitution with null bytes generates warning

On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote: >If users were relying on this behavior (I know I have scripts that read > things from proc -- a text interface that uses \0 to display values similar > to MS's multi-string Values in the Windows registry. >Could you change it

Re: Behavior of ${var/*/text} has changed

On Fri, Sep 16, 2016 at 12:38:20PM -0700, Eric Pruitt wrote: > first time. However, that construct still won't work because if a > variable is defined, it will still choose "not empty:" > > ericpruitt@sinister:~$ X= > ericpruitt@sinister:~$ echo ${X+Not empty} > Not empty Then you

Re: Behavior of ${var/*/text} has changed

On Fri, Sep 16, 2016 at 12:30:59PM -0700, Eric Pruitt wrote: > PS1="${SSH_TTY/?*/\\u@\\h:}\\W${jobs/?*/ [\\j]}\\$ " > > In this example, I want to show the username and hostname if SSH_TTY is > set and not empty, but I do not want to modify its value. I am also > showing the number of

Re: Behavior of ${var/*/text} has changed

On Fri, Sep 16, 2016 at 12:06:53PM -0700, Eric Pruitt wrote: > Bash 4.3: > ericpruitt@sinister:~$ VAR= > ericpruitt@sinister:~$ echo ${VAR/*/VAR was not empty} > > Bash 4.4: > ericpruitt@sinister:~$ VAR= > ericpruitt@sinister:~$ echo ${VAR/*/VAR was not

Re: Command substitution with null bytes generates warning

On Thu, Sep 15, 2016 at 10:51:22PM -0700, Eric Pruitt wrote: > Fix: > Is this even an intentional change? I looked at some of the other > internal_warning invocations, and they were commented out using "#if 0 > ... > #endif." In 4.4-beta2, I see them in subst.c and parse.y and

Re: [Bug] kill -l 0 outputs T, not EXIT

On Tue, Sep 13, 2016 at 05:11:05AM +0200, Martijn Dekker wrote: > The command > > kill -l 0 > > outputs T. I would expect EXIT as T is not a valid signal or > pseudosignal name. Since T is the last letter of EXIT, I suspect a typo > somewhere. My guess is it's just printing the string

Re: Single quote character not handled well in associative array index

On Mon, Aug 29, 2016 at 11:28:47PM -0400, Wesley Hirsch wrote: > ((++a[\$b])) These three also work: (('++a[$b]')) (('++a["$b"]')) : $((++a["$b"])) But yes, this does seem like a bug.

Re: Open pipe passed to child process

On Wed, Aug 24, 2016 at 05:04:17PM -0400, Adam Danischewski wrote: > be allowed, since I do not want things like a squirrely child process > eating up parent pipe data in my while/read loops. http://mywiki.wooledge.org/BashFAQ/089

Re: Open pipe passed to child process

On Wed, Aug 24, 2016 at 02:52:01PM -0400, Adam Danischewski wrote: > When a parent script kicks off a child process, and the child process reads > from fd0 I don't expect the child to be capable of manipulating the parents > pipe data on fd0. An error potentially but not quietly eating up the >

Re: Intriguing error with arithmetic evaluation

On Wed, Aug 24, 2016 at 03:01:09PM +0100, Stephane Chazelas wrote: > Possibly HP-UX changed it? Sounds more likely than > Solaris changing it the other way round. > > What version of ksh is it based on? $ strings /bin/ksh | grep Version | tail -2 @(#)Version 11/16/88 (That command came from

Re: Intriguing error with arithmetic evaluation

On Tue, Aug 23, 2016 at 05:15:25PM +0100, Stephane Chazelas wrote: > POSIX doesn't specify ((...)) (explicitely leaves it > unspecified), so is out of POSIX scope anyway. > > It was introduced by ksh88. > > There and in ksh93 (but not pdksh nor zsh) > > ksh -c '((0)); echo X' > > outputs X

Re: Intriguing error with arithmetic evaluation

On Tue, Aug 16, 2016 at 09:16:50AM -0700, L. A. Walsh wrote: > Perhaps you can explain why bash's "normal mode" had to change? I don't have a "why", but I do note this on http://mywiki.wooledge.org/BashFAQ/105/Answers See the answer for "Exercise 2". I repeat, because it needs to be repeated

Re: Intriguing error with arithmetic evaluation

On Mon, Aug 15, 2016 at 03:15:13AM -0700, L. A. Walsh wrote: > Calculations shouldn't ever trigger "-e" except for things like > division by 0 (which doesn't trigger it, as the calculation dies > before an return value can be calculated); it's counter-intuitive. You may wish as hard as you like,

Re: Intriguing error with arithmetic evaluation

On Fri, Aug 12, 2016 at 02:22:26PM +0530, NO REPLY wrote: > I have a few increment expressions used as ((level++)) and only one of > those is giving an error. When used with set -e, bash aborts > execution. Using ERR trap, I was able to identify the expression.

Re: bash(1) says /etc/bash.bash.logout, should be bash_logout

On Fri, Aug 12, 2016 at 09:59:00AM -0400, d...@fifthhorseman.net wrote: > I think the documentation is wrong about the systemwide filename that > bash reads when a login shell exits. the manpage says > "/etc/bash.bash.logout", but the binary appears to be built with > "/etc/bash.bash_logout"

Re: echo builtin command will give the wrong value of the variable when there is a file named: 11 in the current directory

On Wed, Jul 27, 2016 at 07:24:11PM +0800, Lingfei Kong wrote: > # touch 11 > # c='[11761][1469504252]' > # echo $c > 11 This is why you MUST ALWAYS quote your parameter expansions. echo "$c" http://mywiki.wooledge.org/Quotes http://mywiki.wooledge.org/BashGuide

Re: [Documentation] -d returns true for symlink to directory

On Thu, Jul 21, 2016 at 03:38:40PM -0600, Bob Proulx wrote: > The original option letter used by test to check for the presence of a > symlink was -h. I don't know why. But in those days the only test > option to test for a symlink was -h. The -L came later. This legacy > is still visible in

Re: [Documentation] -d returns true for symlink to directory

On Thu, Jul 21, 2016 at 05:56:13PM +0200, Reuti wrote: > While we are on this: wondering about the difference about -h and -L I found > that `man test` outputs on OS X: > > " -h file True if file exists and is a symbolic link. This > operator is retained for compatibility with pre- >

Re: [Documentation] -d returns true for symlink to directory

On Wed, Jul 20, 2016 at 04:43:13PM -0700, Adam McKenna wrote: >-d file > True if file exists and is a directory. > > The operator also returns True if the file exists and is a symlink to a > directory Yes. All of the file-testing operators follow a symlink, EXCEPT for the

Re: ordering of printed lines changes when redirecting

On Mon, Jul 18, 2016 at 10:22:46AM +0200, walter harms wrote: > ( ./a.out 2>&1 ) > hallo 5 > hallo 6 > hallo 7 > hallo 8 > hallo 9 (snip) > ./a.out >xx 2>&1 > cat xx > hallo 6 > hallo 8 > hallo 5 > hallo 7 > hallo 9 Looks like an artifact of stdio (libc) buffering. When stdout and stderr

Re: Bash-4.4-beta2 available for download

On Wed, Jul 13, 2016 at 11:45:10AM -0400, Greg Wooledge wrote: > On Wed, Jul 13, 2016 at 11:39:50AM -0400, Chet Ramey wrote: > > I was able to retrieve a copy from ftp.cwru.edu using wget (passive mode) > > and an ftp client (extended passive mode). Try it again and let me know

Re: Bash-4.4-beta2 available for download

On Wed, Jul 13, 2016 at 11:39:50AM -0400, Chet Ramey wrote: > I was able to retrieve a copy from ftp.cwru.edu using wget (passive mode) > and an ftp client (extended passive mode). Try it again and let me know > the results. wget ftp://ftp.cwru.edu/pub/bash/bash-4.4-beta2.tar.gz worked for me

Re: Bash-4.4-beta2 available for download

On Tue, Jul 12, 2016 at 09:38:51PM -0400, Chet Ramey wrote: > The second beta release of bash-4.4 is now available with the URL > > ftp://ftp.cwru.edu/pub/bash/bash-4.4-beta2.tar.gz > > and via git from > > http://git.savannah.gnu.org/cgit/bash.git/?h=bash-4.4-testing I have been utterly

Re: Read stdin delimited fails on empty field

On Thu, Jul 07, 2016 at 03:01:31PM -0400, Todd Merriman wrote: > IFS=' ' # TAB > If any fields are empty, the data is read into the preceding field. > In other words, if in the example FLD3 is empty, FLD4 is read into > FLD3. If FLD2 and FLD3 are empty, FLD4 is

Re: Bash 4.3.11(1) crashes after running exec

On Mon, Jun 27, 2016 at 08:25:06PM +0300, #pragma wrote: > Thank you. You are right, it was just confusing to see on the screen of > Konsole terminal that "bash program was crashed". So bash not doing > fork() before exec? It looks like a father process crashes. Crash is > always undesired and

Re: Logging bash commands to a specific file

On Fri, Jun 24, 2016 at 06:08:35AM -0500, Richard Lohman wrote: > I need to log all commands entered at the shell for all users on a host > (business need, not technical). Look at SYSLOG_HISTORY in config-top.h. Configure your syslog daemon and the SYSLOG_LEVEL and SYSLOG_FACILITY in

Re: Possible bash bug?

On Wed, Jun 22, 2016 at 10:34:59AM +0100, John Lawlor wrote: > If I do the following: > > bash -c "ping 127.0.0.1 > $HOME/console.log" & > Now if I kill bash: > > Bash is killed but not the child ping process. I was expecting that to be > killed also. Not a bug. If you want a signal (e.g.

<    4   5   6   7   8   9   10   11   12   13   >