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.
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
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 ccc)
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 end
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 e
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
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
> | origina
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 som
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
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 i
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 thing
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
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
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.
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 <<<'command_not_found_handle () { echo "$FUNCNAME"; }; bla
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
On Wed, Nov 23, 2016 at 1:25 PM, Chet Ramey 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 report. This will be fixed
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 $ ( bash
On Sun, Nov 6, 2016 at 3:46 PM, Chet Ramey wrote:
> On 11/1/16 5:57 AM, Dan Douglas wrote:
>> On a possibly related note, would you consider adjusting +, :+, -, :-,
>> as in "${var[@]+word}" to align with the meaning of [[ -v var[@] ]] as
>> discussed in
>> h
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,
>> otherwise:
>>
>>
>>
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
implemented on the
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.
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 arrays).
> It doesn't seem to
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 assi
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 trivial. It's an assign
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 index is >= that of the
se
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 trav
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'?
+1 for this. I've al
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&
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 d
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 b="a[1]"
I kind of like this
On Thu, Jun 9, 2016 at 4:34 AM, Dan Douglas 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 work
> without having
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
$ mk
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 be useful for the assignment to work, as tha
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 hadn't even tried the ref4
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
internal purposes and enabl
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 tricks
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
>> multi-line aliases out there.
>
>
> I won
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
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
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
affecting subsequent assi
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.
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. : {varname}<&1'
>> the red
On Sun, May 8, 2016 at 6:03 PM, Chet Ramey wrote:
> On 5/5/16 6:02 PM, Dan Douglas wrote:
>> 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
>>
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 variable's value as well?
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.
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 produce locally scoped va
...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 do
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 expanded, but allowed th
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 can
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 important to note that the nameref attribute is throw
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
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
co
aspect of any script
that couldn't have been foreseen. The script is usually to blame.
--
Dan Douglas
https://tiswww.case.edu/php/chet/gpgkey.asc
--
Dan Douglas
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 are identical in ba
On Sat, Feb 20, 2016 at 2:55 PM, Dan Douglas 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 whole thread has some good info.
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.
>
> diff -ur bash-4.
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 around some part of the expression
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.
\On Tue, Feb 16, 2016 at 1:30 AM, Linda Walsh 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 was to do multiple a
1" [1]="2" [2]="3" [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
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 `readon
On Tue, Aug 18, 2015 at 3:50 PM, Chet Ramey wrote:
> On 8/18/15 1:43 PM, Dan Douglas wrote:
>> On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
>>> Would you mind sharing the rational behind having it undocumented?
>>
>> Since I like guessing: the
a=([foo]='([bar]=baz)') "b=${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
are addressed.
--
Dan Douglas
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 th
${var~~} case inversion
> expansion.
> It got the upper and lower, ie ${var^} and ${var,} but not invert.
>
> Fix:
> More documentation.
I'm pretty sure that's intentional. The corresponding `declare -c` has never
been documented either.
--
Dan Douglas
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"
similar) on untrusted user
> input. But don't call it a bash security hole that bash allows you to
> write stupid scripts.
>
>
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 "blah{0..$n}"` is reasonably common and not necessarily stupid.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
On Tue, Jun 2, 2015 at 7:31 AM, Greg Wooledge 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 prevents integers and f
I thought Bash always first splits the identifier from the subscript,
then checks which attributes the variable has set. If it has the
associative array attribute plus a subscript then the subscript is
only processed for expansions and the resulting string is used as the
key. If the associative arr
On Thu, Apr 16, 2015 at 9:50 AM, Greg Wooledge 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
> certainly not o
On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge 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
o redirect operators that can be used together with
`read` to get something like this. They're somewhat difficult to use
IMO:
<#pattern Seeks forward to the beginning of the next line
containing pattern.
<##patternThe same as <# except that the portion of the
ng David
Korn's design. It's obviously half-baked in its current state and hard to use
for getting real work done. It's better than 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
r 01, 2015 at 12: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'
>>
>>
s/255#issuecomment-88452555
-- Forwarded message ------
From: Dan Douglas
Date: Wed, Apr 1, 2015 at 12:15 PM
Subject: Re: [shellcheck] Bash arithmetic expansion diagnostics (#255)
To: koalaman/shellcheck
On Wed, Apr 1, 2015 at 7:07 AM, brother wrote:
>
> I walked straight into one
.0(0)-ksh93'
typeset -n BASH_REMATCH='.sh.match[0]'
typeset -n BASH_SOURCE=file
typeset -n BASH_SUBSHELL=subshell
$ mksh -c 'typeset -p' | grep BASH
typeset -i -U BASHPID=1207
--
Dan Douglas
ne-grained 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
or argument to a command is far more likely to
bite you. Examples:
var=foo>out
let x>5\?y:z
If you're worried about making a mistake, enable the noclobber option
in your bashrc.
--
Dan Douglas
ay ahead of master.
Maybe you have better ideas. It's probably best to do whatever you
plan on your own branch if possible.
--
Dan Douglas
bash can't possibly know about the
option parser of every single command.
--
Dan Douglas
27;. See `help 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
n (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
;${a[${key%_}]}" on each usage. Or at minimum [[ $key ]] on every
iteration of a loop over "${!a[@]}". It's almost uglier than `set -u'
workarounds...
--
Dan Douglas
$ 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 Douglas
ode to either declare something twice in the same scope or rely upon a global
being in a particular state.
--
Dan Douglas
; g; typeset -p
x; }; function g { x="in g"; }; x=global; f; typeset -p x' )
x='in g'
x=global
I would have much preferred if David Korn followed 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
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 say
even means. I understand that read's now basically useless behavior without -r
was originally there to make using it interactively without a line editor
slightly easier.
--
Dan Douglas
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
(foo); print "${@a}"; typeset -T A=(typeset x);
A a=(x=foo); print "${@a}"; a+=(x=bar); print "${@a}"; typeset -p a'
typeset -a A
A
A -a a=((x=foo) (x=bar))
If it were redesigned today there would surely be no attributes, only types.
--
Dan Douglas
s proposal might 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
On Monday, October 06, 2014 02:00:47 PM Linda Walsh wrote:
>
> Greg Wooledge wrote:
> > On Mon, Oct 06, 2014 at 12:38:21PM -0700, Linda Walsh wrote:
> >> According to Chet , only way to do a multi-var assignment in bash is
> >>
> >> read a b c d <<<$(echo ${array[@]})
It's best to avoid turning
On Tuesday, September 30, 2014 12:11:15 AM Andreas Schwab wrote:
> Dan Douglas writes:
>
> > Another thing you can do in bash is bypass its command name check by using
> > a
> > null zeroth word.
> >
> > $ { function } { echo test; }; <() }; }
> >
gt; why POSIX should force a shell to reject a function whose name
> doesn't contain a valid identifier.
> ...
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, but appare
on, or dash were to make some improvements to make me
care about its locals, among other things.)
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
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
>
code in examples/functions/autoload.*. I believe it serves
mostly the same purpose as exported functions.
--
Dan Douglas
1 - 100 of 269 matches
Mail list logo
