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
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
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
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
> |
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
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
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
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
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
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 <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
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 $ (
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,
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
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
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
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
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
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
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'?
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
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
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
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
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
$
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
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
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
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
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
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
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. :
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
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
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
...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
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
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
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
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
common aspect of any script
that couldn't have been foreseen. The script is usually to blame.
--
Dan Douglas
Bugs
Encrypt with: 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
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
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.
>
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
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 <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
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
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
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.
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
=${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
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
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
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
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
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
is copied to standard output.
--
Dan Douglas
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
-- 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
: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
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
'typeset -p' | grep BASH
typeset -i -U BASHPID=1207
--
Dan Douglas
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
ideas. It's probably best to do whatever you
plan on your own branch if possible.
--
Dan Douglas
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
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
]] on every
iteration of a loop over ${!a[@]}. It's almost uglier than `set -u'
workarounds...
--
Dan Douglas
be no attributes, only types.
--
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
A -a x=((y=foo) (y=bar))
--
Dan Douglas
without a line editor
slightly easier.
--
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 says how to read the
line; the -r option affects
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
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
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
rewinding the input.
--
Dan Douglas
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
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
improvements to make me
care about its locals, among other things.)
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
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
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
the status. For
set -e the former is the only option.
--
Dan Douglas
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
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
}!' ~/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
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
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 - 100 of 241 matches
Mail list logo