Re: bash 5.0 nested array subscript arithmetic expansion error

On Wed, Oct 17, 2018 at 9:05 AM Chet Ramey wrote: > You know this has already been done, right? I do now! Still trying to get caught up with the changelog.

Re: bash 5.0 nested array subscript arithmetic expansion error

On Mon, Aug 27, 2018 at 8:12 PM Chet Ramey wrote: > > On 8/27/18 12:25 PM, Grisha Levit wrote: > > This used to work: > > > > bash-4.4$ a=0 > > bash-4.4$ echo $(( a[a[0]] )) > > 0 > > bash-4.4$ echo ${a[a[a[0]]]} > > 0 Just curious, did you decide what to do with this? > This is part of changes

Re: Array not defined when being set inline

On 10/10/2017 07:00 AM, shawn wilson wrote: > I guess that's the right way to describe what I'm seeing: > > [swilson@localhost ~]$ unset f; f=(aaa bbb ccc) declare -p f > declare -x f="(aaa bbb ccc)" > [swilson@localhost ~]$ unset f; f=("aaa" "bbb" "ccc") declare -p f > declare -x f="(aaa bbb

Re: command_not_found_handle documentation omission

On 10/08/2017 03:11 PM, Eduardo A. Bustamante López wrote: > I guess that instead of changing the semantics of > command_not_found_handle, a new special trap could be added that > executes in the context of the shell performing the command lookup. Possible, but magic traps can be ugly. I often

Re: command_not_found_handle documentation omission

On 10/08/2017 10:41 AM, Dan Douglas wrote: > On 10/08/2017 09:47 AM, Chet Ramey wrote: >> It was originally intended to take the place of the error message that >> bash prints when it can't find a program to execute. That message was >> printed by the subshell forked to ex

Re: command_not_found_handle documentation omission

On 10/08/2017 09:47 AM, Chet Ramey wrote: > It was originally intended to take the place of the error message that > bash prints when it can't find a program to execute. That message was > printed by the subshell forked to execute the command, so the message could > be redirected (nearly ll shells

Re: command_not_found_handle documentation omission

On 10/07/2017 02:53 PM, Martijn Dekker wrote: > The bash manual and info pages state: > > | If the search is unsuccessful, the shell searches for a > | defined shell function named 'command_not_found_handle'. If that > | function exists, it is invoked with the original command and the > |

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

On 10/05/2017 02:29 PM, Dan Douglas wrote: > ... Another band-aid might be to build bash with -fsplit-stack. Hardly worth mentioning as it doesn't fix anything - you just run out of memory instead of overflowing a fixed-size stack, should someone actually want that for some rea

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

On 09/25/2017 01:38 PM, Eric Blake wrote: > On 09/24/2017 12:53 PM, Shlomi Fish wrote: > >> >> I see. Well, the general wisdom is that a program should not ever segfault, >> but >> instead gracefully handle the error and exit. > > This is possible by installing a SIGSEGV handler that is able to

Re: /bin/sh should set SHELL to /bin/sh

On 07/14/2017 03:13 PM, Greg Wooledge wrote: > On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote: >> IMO, if SHELL gets unset (it is usually initialised by login, or its >> equivalent), it should simply stay unset, and not be set to anything, >> until some user (or script) decides to set

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

On 03/18/2017 12:19 PM, Chet Ramey wrote: > On 3/17/17 6:35 PM, Dan Douglas wrote: > >> The problem is the non-obvious nature of unset's interaction with scope, >> (and the lack of documentation). Not much can be done about the former, >> as it is with so many things. &g

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

On 03/17/2017 09:16 PM, Dan Douglas wrote: > Why > would a subshell just make the call stack go away? I guess slight correction, it's unset itself, because: > In fact, mksh prints "global" even without the subshell, despite it > using dynamic scope for either func

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

On 03/17/2017 07:21 PM, Stephane Chazelas wrote: > I don't expect the need to have to add "local var" in > > ( >unset -v var >echo "${var-OK}" > ) True. I would pretty much never use a subshell command group when I know that locals are available though. And if I know locals are available

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

The need to localize IFS is pretty obvious to me - of course that's given prior knowledge of how it works. The problem is the non-obvious nature of unset's interaction with scope, (and the lack of documentation). Not much can be done about the former, as it is with so many things.

Re: command_not_found_handle and sourced script

On Mon, Dec 26, 2016 at 12:42 PM, Dominique Ramaekers wrote: > As I understand it, the command_not_found_handle is not triggered on an > unknown command in a shell script, run normally. Where'd you here that? That's easy to test. $ bash

Nonterminating alias

A simpler one this time. Bash 4.4 only. $ bash -c $'alias @="eval {\n}"; eval @' bash: xrealloc: cannot allocate 18446744071562068464 bytes I would guess this is part of the way keywords are supposed to be re-interpolated after alias expansion since 4.4. Maybe not even be a bug depending on how

Re: Command or process substitution resets alias name tracking during alias expansion?

On Wed, Nov 23, 2016 at 1:25 PM, Chet Ramey <chet.ra...@case.edu> wrote: > On 11/22/16 5:46 PM, Dan Douglas wrote: >> Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4. >> (Added the counter to make it stop). > > Thanks for the incredibly obscure

Command or process substitution resets alias name tracking during alias expansion?

Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4. (Added the counter to make it stop). ormaajtest@smorgbox $ ( bash-4.2 ) <<\EOF shopt -s expand_aliases; n=0 alias @='((n >= 5)) && alias @="unalias @; echo" printf "$((n++)) " $() @' @ EOF 0 1 2 3 4 5 ormaajtest@smorgbox $ (

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

On Mon, Oct 24, 2016 at 8:25 AM, Chet Ramey wrote: > On 10/21/16 5:41 PM, L. A. Walsh wrote: >> On 4.3 and earlier, at least on arrays, one could have >> the illusion of this working w/o complaint -- and returning >> 0 when the array was 0-len or unset, or the array length,

Re: for Chet Ramney in Born Againe

On Mon, Oct 24, 2016 at 8:33 AM, Корень Зла wrote: > Can u re:coded BASH for Power Shell features to fully intagrated with Linux > enviroments Directly supporting features in a compatible way would not be easy. Powershell is a completely different language, and bash isn't yet

Re: [minor] Space after last element on assoc print

By the way, that space at the end has been pointed out a number of times lately. I think Chet clarified at some point that that's just the way the serializer prints it - so it's nothing. Apparently a lot of people think it's meaningful.

Re: [minor] Space after last element on assoc print

On Wed, Oct 19, 2016 at 11:47 PM, Quentin L'Hours wrote: > Hi, > > Bash Version: 4.4 > Release Status: release > > Description: > > Useless space after last item of a declare -p on an assoc array (indexed > arrays don't print it, and neither does ksh typeset on assoc

Re: Is this the expected behaviour for nameref in Bash 4.4 now?

Yes that was an intentional change to require valid identifiers. I can't say it will always be that way or that there won't at some point be a workaround. You can stiill use `${!param}' for now to refer to positional parameters as you always could, but as usual that isn't useful if you want to

Re: Assigning to BASHPID fails silently

On Thu, Oct 20, 2016 at 2:35 PM, Chet Ramey wrote: > On 10/20/16 11:32 AM, Martijn Dekker wrote: > >> So, in some contexts this bug causes a premature exit of the shell, in >> others it causes a premature exit of a loop. This bug hunt could get >> interesting. > > No, it's

Re: Magnitude of Order "For Loop" performance deltas based on syntax change

On Mon, Sep 26, 2016 at 3:32 PM, Chet Ramey wrote: > So you want offset N to be the nth element in the array instead of the > element with index N? Huh. Maybe, not always. Both would be nice. The offset isn't the element with the index N. It's the next set element whose

Re: Magnitude of Order "For Loop" performance deltas based on syntax change

Would an array of pointers to structs of key-value pairs be better here? It should be faster in the common cases even though it may mean some wasted space and reallocs depending on how you decide to grow the array. A linear search through an array for an index should be faster than linked-list

Re: Location of configuration files

On Thu, Aug 18, 2016 at 5:34 AM, Joonas Saarinen wrote: > Hi, > > By default Bash uses these files in my home directory: > > .bashrc > .bash_logout > .bash_history > .profile > > However, wouldn't it be more streamlined to place these files under > directory '~/.config/bash'?

Re: "until continue" causes bash to exit.

On 07/19/2016 09:45 PM, Chet Ramey wrote: > On 7/19/16 7:15 PM, Dan Douglas wrote: >> Hi, I could reproduce this in all bash versions. >> >> bash -c 'set -x; until continue; do :; done; echo test1'; echo test2 >> + continue >> test2 >> >> I'm not a

"until continue" causes bash to exit.

Hi, I could reproduce this in all bash versions. bash -c 'set -x; until continue; do :; done; echo test1'; echo test2 + continue test2 I'm not actually sure whether this is supposed to work at all. Almost all shells do something strange when given continue in the first compound-list. E.g. ksh93

Re: Global variable modification by nameref chain

On Sun, Jun 12, 2016 at 8:33 PM, Chet Ramey wrote: > 3. Honor the assignment and delete the nameref variable, creating a new >one, like bash-4.3: > > $ ../bash-4.3-patched/bash ./x1 > declare -n a="b" > declare -n b="a[1]" > declare -a a='([1]="foo")' > declare -n

Re: Global variable modification by nameref chain

On Thu, Jun 9, 2016 at 4:34 AM, Dan Douglas <orm...@gmail.com> wrote: > How about just doing it similar to the way mksh resolves arithmetic > variable loops? As each variable is visited, add it to a list (or hash > set) and check whether that node was already visited. That should

Re: Global variable modification by nameref chain

How about just doing it similar to the way mksh resolves arithmetic variable loops? As each variable is visited, add it to a list (or hash set) and check whether that node was already visited. That should work without having to consider scope issues. $ mksh -c 'a=b b=c c=d d=1; echo $((a))' 1 $

Re: Global variable modification by nameref chain

On Sat, Jun 4, 2016 at 5:48 PM, Grisha Levit wrote: > On May 23, 2016 1:42 PM, "Chet Ramey" wrote: >> > Should the assignment work? I'm considering changing the >> > assignments to >> > work more like the references. >> > >> > I think it would

Re: a == a[0] convention

On Thu, Jun 2, 2016 at 12:18 PM, Grisha Levit wrote: > I think all of the stuff here is fixed in the latest devel snapshot Ah ok I tried this again. Yes this looks better now, thanks. > there is definitely weirdness if you run the assignments as a typeset > command. I

Re: RFC: Enabling or disabling tracing shell functions

On Sun, Jun 5, 2016 at 8:48 PM, Chet Ramey wrote: > "Traced functions inherit the DEBUG and RETURN traps from the calling > shell." Why did RETURN originally get sucked into set -T? Was it supposed to be primarily for debugging? Some functions actually use it for

Re: RFC: Enabling or disabling tracing shell functions

Not sure exactly how zsh does it but I know not having the option for both global and local tracing can be annoying. The two big ways of handling xtrace I mostly see are either bash's global `set -x` or ksh93's per-function tracing, and it can be annoying to be missing either one. There are

Re: Mulit-line aliases and PROMPT_COMMAND

On Thu, Jun 2, 2016 at 7:18 PM, Grisha Levit wrote: > > On Thu, Jun 2, 2016 at 6:57 PM, Chet Ramey wrote: >> >> > Since bash 4.3 multi-line aliases interact very strangely >> >> And you're the first person to report them. I guess there aren't a lot of

a == a[0] convention

This is possibly relevant to some of Grisha's observations. First, declaring or assigning to a variable with a subscript. I think I would prefer these to be errors for various reasons. Admittedly there's an argument for making one or both of these non-errors for declarations without assignment for

Re: {ref}<&- does not work on array reference subscripts

You also noticed it runs in a subshell generally. Do you expect something different here? I think <&- should be consistent. On Wed, Jun 1, 2016 at 5:15 PM, Grisha Levit wrote: > declare -n ref=var[0] > {ref} {ref}<&- # fails

Re: redirections preceded by a word with builtins inconsistent

On Tue, May 24, 2016 at 10:23 AM, Chet Ramey wrote: > It's not that Posix `allows' a subshell, it requires a subshell > environment: Hm sorry I thought it was "may". This is kind of easy to confuse with all the other unspecified things about side-effects from assignments

Re: coproc and existing variables

I don't even see why we need a magic variable for this. ksh makes you manually store $! and bash also allows this. As an alternative, create a special BASH_COPROC_PIDS associative array to map coproc names to pids. ${foo}_suffix=bar is never as good as an associative array.

Re: redirections preceded by a word with builtins inconsistent

On Sun, May 22, 2016 at 1:06 PM, Chet Ramey wrote: > On 5/21/16 5:16 PM, adonis papaderos wrote: > >> Bash Version: 4.3 >> Patch Level: 42 >> Release Status: release >> >> Description: >> When using redirections preceded by a word on builtins >> 'i.e. :

Re: namref dicussion continued: [PATCH] export -r reference

On Sun, May 8, 2016 at 6:03 PM, Chet Ramey <chet.ra...@case.edu> wrote: > On 5/5/16 6:02 PM, Dan Douglas wrote: >> On Thu, May 5, 2016 at 2:46 AM, Piotr Grzybowski <narsil...@gmail.com> wrote: >>> ok, so Dan wants this patch. >> >> Yes I think your bash

Re: Global variable modification by nameref chain

On Fri, May 6, 2016 at 8:28 AM, Grisha Levit wrote: > The issue I was trying to raise is that assignment modifies the global > variable but expansion uses the local value. > If the assignment to the global variable is intentional, then shouldn't > expansion use the global

Re: namref dicussion continued: [PATCH] export -r reference

Oh I see you talked about some of this already in the "chained nameref" thread. I haven't read that one yet... I wonder why `export -r` requires a different solution because it's pretty much the same underlying problem.

Re: namref dicussion continued: [PATCH] export -r reference

On Thu, May 5, 2016 at 2:46 AM, Piotr Grzybowski wrote: > ok, so Dan wants this patch. Yes I think your bash patch is probably an improvement at least in this particular case. > Maybe you can comment on wether the patches are valid. The posix export and readonly don't

Re: param expansion with single-character special vars in the environment

...Also remember it isn't feasible to actually validate a "name" in a script because a name can contain a subscript with a command substitution that effectively requires parsing the full language. (there are some tricks like with `set -nv` and reading its output to shanghai the shell parser into

Re: param expansion with single-character special vars in the environment

On Wed, May 4, 2016 at 2:37 PM, Piotr Grzybowski wrote: > > On 4 May 2016, at 17:51, Chet Ramey wrote: > >> The issue I'm thinking about currently is whether or not to allow nameref >> variables to have numeric (integer) values. bash-4.3 didn't allow those >> values to be

Re: namref dicussion continued: [PATCH] export -r reference

Yeah I was just looking for this old script last night and just found it :) https://gist.github.com/ormaaj/04923e11e8bdc27688ad If you scroll down to the output for "test 3" where "h" gets called and passes a local "x" to a function that creates a reference to it and exports the reference you

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 1:59 PM, Grisha Levit wrote: > > On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: >> >> and this one throws away the nameref attribute: >> >> typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > > > I think it's

Array expansions in scalar assignments

Hi, it looks like these expansions still aren't quite being delimited by IFS consistently. Probably strangest of these is a4 where `$*` doesn't agree with `${a[*]}`, and a3 vs. a4 where quoting modifies the result. I would think bash should look like the ksh output with all @'s space-separated and

Re: [patch] /* XXX - possibly run Coproc->name through word expansion? */

FWIW, something like this works currently. This pattern is useful in a bunch of situations where the shell wants to assign to a fixed variable name. (getopts being another). ~ $ bash /dev/fd/9 9<<\EOF function mkProcs { typeset -n COPROC ref=$1 set -- "${ref[@]}" for COPROC; do

Re: Security Vulnerability Reporting

common aspect of any script that couldn't have been foreseen. The script is usually to blame. -- Dan Douglas

Re: Security Vulnerability Reporting

Bugs Encrypt with: https://tiswww.case.edu/php/chet/gpgkey.asc -- Dan Douglas

Re: [PATCH] admit 'typeset' is here to stay

On Sat, Feb 20, 2016 at 5:28 PM, Martijn Dekker wrote: > Am I missing something? I thought they did exactly the same thing in > bash. If I'm not wrong about that, then as far as bash is concerned, > they are in fact synonyms and functionally equivalent. Yes declare and typeset

Re: [PATCH] admit 'typeset' is here to stay

On Sat, Feb 20, 2016 at 2:55 PM, Dan Douglas <orm...@gmail.com> wrote: > http://thread.gmane.org/gmane.comp.standards.posix.austin.general/8371/focus=8377 I meant to post Chet's reply to my question: http://article.gmane.org/gmane.comp.standards.posix.austin.general/8482 But that who

Re: [PATCH] admit 'typeset' is here to stay

On Thu, Jan 28, 2016 at 4:36 PM, Martijn Dekker wrote: > In 'help typeset', the 'typeset' builtin is called obsolete and has been > so since at least bash 2.05b (2002) or possibly earlier. Perhaps it's > time to just call it a synonym, as indeed the texinfo documentation does. >

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

On Mon, Feb 8, 2016 at 9:20 AM, Stephane Chazelas wrote: > 2016-02-08 09:00:09 -0500, Chet Ramey: >> On 2/8/16 2:47 AM, Linda Walsh wrote: >> > When you are doing a var expansion using the >> > replacement format ${VAR//./.}, is there some way to >> > put parens

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

Sorry, spoofed identity (thanks gmail for picking a random sender). I'll be rid of gmail as soon as I get a little free time.

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

\On Tue, Feb 16, 2016 at 1:30 AM, Linda Walsh <b...@tlinx.org> wrote: > > > 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 w

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

ot; [3]="4" [4]="4" [5]="5") I almost think it makes sense to treat ordered and unordered collections differently. With an unordered collection an outer += should obviously mean "add or update for each assignment". For an ordered collection when appending beginning at an index lower than the max index I'm not so sure. -- Dan Douglas

Re: `foo=1 declare -r foo' prints an error message but its exit status is zero

On Wednesday, September 9, 2015 2:17:30 PM CDT ziyunfei wrote: > $ foo=1 declare -r foo > bash: foo: readonly variable > $ echo $? > 0 > $ echo $foo > 1 > > Is this a bug? > > $ bar=1 readonly bar; # throw an error in Bash 4.2, fixed in Bash 4.3 It's a bit more illustrative when you use

Re: Integer Overflow in braces

to overflow is separate from the question of whether the resulting expansion is too big. Code that does an `eval blah{0..$n}` is reasonably common and not necessarily stupid. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Parameter Expansion: Case Modification: ${var~} not documented

for the circumfix operators `!var[@]` and `!var[*]` that collide with the prefix `!` operator, and for reasons unknown don't interoperate with any of the other expansions such as array slicing / subscripting. I wouldn't want to add new (pointless) syntax before the fundamental problems are addressed. -- Dan

Re: quoted compound array assignment deprecated

=${a[$key1]} typeset -p a b; echo ${b[$key2]} ) declare -A a='([foo]=([bar]=baz) )' declare -A b='([bar]=baz )' baz Any change will likely break this property but I think wrapping it in eval gives the same result. -- Dan Douglas

Re: Integer Overflow in braces

On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote: On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote: IMHO the issue of whether the integer is allowed to overflow is separate from the question of whether the resulting expansion is too big. Code that does an `eval

Re: Parameter Expansion: Case Modification: ${var~} not documented

On Tuesday, August 18, 2015 08:50:51 AM Dan Douglas wrote: I'm pretty sure that's intentional. The corresponding `declare -c` has never been documented either. Hrm, it doesn't correspond actually. declare -c just capitalizes the first letter of the string. Another thing about the ${var

Re: unset does not act as expected on namerefs

On Tue, Jun 2, 2015 at 7:31 AM, Greg Wooledge wool...@eeg.ccf.org wrote: There's declare -i, but no sane person USES that, so we can ignore it. While in bash `-i` likely either has no effect or slows things down very slightly, in ksh93 and probably zsh it's a huge performance win because it

Re: Request to a new feature on read

On Thu, Apr 16, 2015 at 9:50 AM, Greg Wooledge wool...@eeg.ccf.org wrote: I don't see why such features should be compiled into bash's read builtin. I'd have no problem with adding better splitting/joining/parsing features in a more general context, probably operating on a string variable, but

Re: Request to a new feature on read

On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote: I find myself in need of something along the lines of Python's `re.split` and `re.findall` all the time. E.g. splitting an ip into an array of octets. IFS

Re: Request to a new feature on read

is copied to standard output. -- Dan Douglas

Re: [Help-bash] make function local

nothing I guess. Anyway, you can probably do something resembling FP with some combination of `typeset -T` wrappers to contain your functions, and `typeset -M` and `-C` to move and copy objects around by reference. It's not pretty. -- Dan Douglas

Fwd: [shellcheck] Bash arithmetic expansion diagnostics (#255)

-- Forwarded message -- From: Dan Douglas orm...@gmail.com Date: Wed, Apr 1, 2015 at 12:15 PM Subject: Re: [shellcheck] Bash arithmetic expansion diagnostics (#255) To: koalaman/shellcheck reply+0003e7c2a607770e1564420080ff167a99c7ac0c55c501de92cf00011133a16592a169ce02dfd

Re: Fwd: [shellcheck] Bash arithmetic expansion diagnostics (#255)

:53:16PM -0500, Dan Douglas wrote: Hi, This was noticed in a comment to a github issue. Just forwarding it along. $ for ((; 1(1) ;)); do break; done -bash: syntax error near unexpected token `newline' $ echo $BASH_VERSION 4.3.33(1)-release https://github.com/koalaman

Re: definite way to determine the running shell

feature detection. Something like that is on my todo list for some day. https://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/getshver?rev=HEAD http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh.html http://stchaz.free.fr/which_interpreter -- Dan Douglas

Re: definite way to determine the running shell

'typeset -p' | grep BASH typeset -i -U BASHPID=1207 -- Dan Douglas

Re: Feature: disallow |

you. Examples: var=fooout let x5\?y:z If you're worried about making a mistake, enable the noclobber option in your bashrc. -- Dan Douglas

Re: Experiment to provide a mirror of bash with detailed git history

ideas. It's probably best to do whatever you plan on your own branch if possible. -- Dan Douglas

Re: how to search for commands

type' for how to use it. Searching for commands by package is OS-specific. e.g. in Gentoo `equery f -f cmd pkg' will show commands belonging to a package. Cygwin's equivalent is `cygcheck -l'. Pretty much every distro has something similar. -- Dan Douglas

Re: array subscripts act differently for integers(ie. let)

expansions). However if you disabled evaluating parameter expansions during variable resolution (for array indexes) then you would be stuck with exactly the above ksh problem. It's unfortunate people don't understand this, but when you think about it it can't really work any other way. -- Dan Douglas

Re: array subscripts act differently for integers(ie. let)

]] on every iteration of a loop over ${!a[@]}. It's almost uglier than `set -u' workarounds... -- Dan Douglas

Re: declare a=$b if $a previously set as array

be no attributes, only types. -- Dan Douglas

Re: declare a=$b if $a previously set as array

Sorry I did a bad job copy/pasting then editing that last example. ksh -c 'typeset -a x=(foo); print ${@x}; typeset -T A=(typeset y); A x=(y=foo); print ${@x}; x+=(y=bar); print ${@x}; typeset -p x' typeset -a A A A -a x=((y=foo) (y=bar)) -- Dan Douglas

Re: Bash bug - in read -e -r var

without a line editor slightly easier. -- Dan Douglas

Re: Bash bug - in read -e -r var

On Monday, December 15, 2014 10:47:29 AM Chet Ramey wrote: On 12/15/14, 7:11 AM, Dan Douglas wrote: I'm generally interested in what read with (or without) -r combined with -e even means. I'm not sure what you're driving at. The -e option says how to read the line; the -r option affects

Re: declare a=$b if $a previously set as array

his original proposal of adding dynamic scope for only POSIX-style function definitions across the board. At least porting bash scripts will be slightly easier in the very specific case that ksh is invoked correctly. -- Dan Douglas

Re: declare a=$b if $a previously set as array

in bash's current behavior and doesn't need to change (-a vs no -a): $ bash -c 'x=[4]=foo [6]=bar; declare -a y=($x); declare -p y' declare -a y='([4]=foo [6]=bar)' $ bash -c 'x=[4]=foo [6]=bar; declare y=($x); declare -p y' declare -- y=([4]=foo [6]=bar) -- Dan

Re: [RFC] Logically composable variant of errexit

be to try cloning zsh's try/catch. It would be familiar to programmers and of course having a pre-existing implementation is a plus. try/catch is probably more intrusive than my first proposal due to the additional keywords and control flow changes. -- Dan Douglas

Re: bash uses tmp files for inter-process communication instead of pipes?

rewinding the input. -- Dan Douglas

Re: REGRESSION: shellshock patch rejects valid function names

in bash is bypass its command name check by using a null zeroth word. $ { function } { echo test; }; () }; } test Ordinarily } would be uncallable, but apparently since bash only checks the command name of the first word, calling with e.g. `() }` or `$() }` works. -- Dan Douglas signature.asc

Re: REGRESSION: shellshock patch rejects valid function names

On Tuesday, September 30, 2014 12:11:15 AM Andreas Schwab wrote: Dan Douglas orm...@gmail.com writes: Another thing you can do in bash is bypass its command name check by using a null zeroth word. $ { function } { echo test; }; () }; } test Ordinarily } would be uncallable

Re: REGRESSION: shellshock patch rejects valid function names

improvements to make me care about its locals, among other things.) -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Issues with exported functions

compatible. Have you considered the FPATH mechanism? Exploiting it requires being able to create files and set FPATH accordingly. I've had some success with the function loader code in examples/functions/autoload.*. I believe it serves mostly the same purpose as exported functions. -- Dan

Re: Issues with exported functions

On Thursday, September 25, 2014 10:29:16 AM Chet Ramey wrote: On 9/25/14, 10:25 AM, Dan Douglas wrote: Have you considered the FPATH mechanism? Exploiting it requires being able to create files and set FPATH accordingly. I've had some success with the function loader code in examples

Re: 'declare' does not honor '-e' in command substituted assignments - a bug ?

the status. For set -e the former is the only option. -- Dan Douglas

Re: Tilde expansion during command search

On Friday, August 01, 2014 06:20:28 AM Mike Frysinger wrote: On Wed 23 Jul 2014 08:51:19 Dan Douglas wrote: On Wednesday, July 23, 2014 09:28:02 AM you wrote: On 7/23/14, 8:22 AM, Dan Douglas wrote: Hi, from this discussion: https://github.com/koalaman/shellcheck/issues/195

Re: Tilde expansion during command search

to what happens during command search appears to have been removed. I agree that if the quoted sentence were present it would probably imply that this behavior is explicitly disallowed. -- Dan Douglas

Tilde expansion during command search

}!' ~/tmpdir/testscript chmod u+x ~/tmpdir/testscript PATH=\~/tmpdir typeset -p PATH testscript ) declare -x PATH=~/tmpdir Hello from /home/devtest/tmpdir/testscript! $ echo $BASH_VERSION 4.3.18(1)-release -- Dan Douglas

Re: Tilde expansion during command search

On Wednesday, July 23, 2014 09:28:02 AM you wrote: On 7/23/14, 8:22 AM, Dan Douglas wrote: Hi, from this discussion: https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 I can't find any reference that says substituting a literal tilde in PATH should occur during

Re: Tilde expansion during command search

On Wednesday, July 23, 2014 07:58:26 AM Eric Blake wrote: On 07/23/2014 07:51 AM, Dan Douglas wrote: On Wednesday, July 23, 2014 09:28:02 AM you wrote: On 7/23/14, 8:22 AM, Dan Douglas wrote: Hi, from this discussion: https://github.com/koalaman/shellcheck/issues/195#issuecomment

  1   2   3   >