$ 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
;${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
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
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
bash can't possibly know about the
option parser of every single command.
--
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
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
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
.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
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
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'
>>
>>
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
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
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
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
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 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
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 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"
${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 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
are addressed.
--
Dan Douglas
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
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
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
Is there a way of outputting a datestamp to shell stderr at the _beginning_
of the execution of a command, that won't wipe out $_?
I use $_ quite a bit for the last argument to the previous command,
interactively. And I'd like to datestamp all my commands. Datestamping
after with $PS1 is easy, bu
I've created a small diff against tonight's bash master branch for
displaying a (single!) prompt after reading a command but before executing
said command.
It's kind of like trapping debug, but it doesn't output the prompt once for
each subcommand in a pipeline - it's just once for the thing you t
On Sat, Oct 24, 2015 at 7:00 PM, Dan Stromberg
wrote:
>
>
> dstromberg@server:~/src/bash/src$ export PS0='fred>
> > '
>
I have no idea where that second > came from; please ignore it.
I just noticed there's an fprintf buglet in there.
I've put a fixed version of at
http://stromberg.dnsalias.org/~strombrg/diffs/ps0-diffs - rather than
inflict another shar on the list :)
Thanks again.
I'd like to be able to log my commands' start and stop times (for good post
mortem analysis), without overwhelming a disk or increasing my
cut-and-paste spruce-up time.
Thanks.
On Sat, Oct 24, 2015 at 9:34 PM, Dan Stromberg
wrote:
>
> I just noticed there's an fprintf b
On Thu, Oct 29, 2015 at 4:35 PM, Chet Ramey wrote:
> On 10/24/15 10:00 PM, Dan Stromberg wrote:
> >
> > I've created a small diff against tonight's bash master branch for
> > displaying a (single!) prompt after reading a command but before
> executing
> >
I've been using the bash 4.4 beta lately.
I'm finding that when I have a long one-liner, bash 4.4 will scroll
horizontally instead of wrapping to the next line. Some people may prefer
this behavior, but I don't.
I tried fiddling with horizontal-scroll-mode, but that didn't appear to
help.
I don
On Mon, Nov 23, 2015 at 5:13 AM, Greg Wooledge wrote:
> On Fri, Nov 20, 2015 at 02:37:29PM -0800, Dan Stromberg wrote:
> > I'm finding that when I have a long one-liner, bash 4.4 will scroll
> > horizontally instead of wrapping to the next line. Some people may
> prefer
&
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 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
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 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
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 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 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
https://tiswww.case.edu/php/chet/gpgkey.asc
--
Dan Douglas
aspect of any script
that couldn't have been foreseen. The script is usually to blame.
--
Dan Douglas
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
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
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
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 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
...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 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 loc
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 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?
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 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
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 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
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
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
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
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 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
Tab expansion works for both parts of
$ some_command < some_file
but not the some_command of
$ < some_file some_command
BASH_VERSION='4.4.0(1)-rc1'
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 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
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 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
Here we observe that bash _could_ first expand as much as it could,
before asking us y or n,
$ find .backups/\!h
Display all 277 possibilities? (y or n) n
$ find .backups/\!home\!jidanni\!
Instead it waits until we say "n".
(All I typed was the first line, and the "n").
BASH_VERSION='4.4.0(1)-rc
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
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 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&
$ bla1 bla2 bla3 &
$
$ &
Why not
$ bla3
What value is remembering "&".
Emacs' doesn't, and doesn't bother even mentioning it:
C-c . runs the command comint-insert-previous-argument, which is an
interactive compiled Lisp function in `comint.el'.
It is bound to C-c ..
(comint-insert-previous-a
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/local
On Thu, Aug 4, 2016 at 2:36 PM, Chet Ramey wrote:
> On 8/4/16 12:05 PM, Dan Cross wrote:
> > Bash Version: 4.3
> > Patch Level: 30
> > Release Status: release
> >
> > Description:
> > When bash is built without job control, shell scripts that use
&g
On Fri, Aug 5, 2016 at 3:22 PM, Chet Ramey wrote:
> On 8/4/16 5:04 PM, Dan Cross wrote:
>
> > Thanks for the report. I took a quick look at this, and it's not
> disabling
> > job control that does it: it's disabling both job control and nls.
> >
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 the bash page at the end of
Readline Command Names
The following is a list of the names of the commands and the default
key sequences to which they are bound. Command names without an accom-
panying key sequence are unbound by default. In the following descrip-
Furthermore, one could finally do
$ run_readline_command dump-variables | grep bell
prefer-visible-bell is set to `on'
bell-style is set to `audible'
which is rather impossible, even if one does bind unbound commands.
Currently one must probably use script(1), bind the key, and then exit
and grep
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 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
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
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 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
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 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
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 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
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 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
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 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
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 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
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/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
>>>>> "CR" == Chet Ramey writes:
CR> On 3/24/24 11:39 PM, Lawrence Velázquez wrote:
>> On Sun, Mar 24, 2024, at 11:01 PM, Dan Jacobson wrote:
>>> P.S., "\t%s" seems to have an extra space squeezed between them with
>>> bash: "\t
GS}, and the parent and child
> make instances cooperate to limit the number of parallel make processes.
Passing -j to submakes ist just wrong. All submakes and the parent
should be part of ONE GNU make jobserver.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
AGS) and rely on make to pass MAKEFLAGS to submakes
> in the environment.
Could you do this for the next alpha release, please?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Fri, 26 Apr 2024 at 15:10, Chet Ramey wrote:
>
> On 4/25/24 9:56 PM, Dan Shelton wrote:
>
> >> Everyone seems to support MAKEFLAGS by now, and it's part of POSIX, so
> >> maybe we delete $(MFLAGS) and rely on make to pass MAKEFLAGS to submakes
> >> in t
It seems these should both make one line "+ a=b c=b" output,
for s in sh bash
do $s -xc 'a=b c=$a'
done
I mean they give the same results, but bash splits it into
two lines, so the user reading the bash -x output cannot tell
if one (correct) or two (incorrect) lines were used.
They can tell with
$ echo \#!/usr/bin/python > k
$ chmod +x k
$ ./k
bash: ./k: cannot execute: required file not found
Bash should really mention what file it is talking about.
$ echo 'x:k; ./$<' > Makefile
$ make
./k
make: ./k: No such file or directory
make: *** [Makefile:1: x] Error 127
$ ls ./k
./k
Make is wor
$ history
is nice, but what if you want to have it read from a different file?
$ help history
says
If FILENAME is given, it is used as the history file. Otherwise,
if HISTFILE has a value, that is used, else ~/.bash_history.
Alas, it also says
history: history [-c] [-d offset] [n] or
301 - 400 of 471 matches
Mail list logo
