On Tuesday, April 09, 2013 10:23:34 PM Chet Ramey wrote:
> On 4/9/13 9:56 PM, Dan Douglas wrote:
> > Erm, here it is in a less unreadable format:
>
> It is pretty slow. You forgot to enable `extglob'.
D'oh!
Bad algorithm? I suppose it's lots of backtracki
ay to handle signals in shell. They don't have to
be complicated.
http://mywiki.wooledge.org/ProcessManagement
http://mywiki.wooledge.org/SignalTrap
--
Dan Douglas
e
behavior of $! was either a nonstandard extension or unintentional bug. Check
the changelog.
--
Dan Douglas
89 2790
dash: empty 2793 2794 2795 2796
zsh: 0 2800 2801 2802 2803
mksh: empty 2807 2809 2810 2811
ksh: empty 2814 2815 2816 2817
posh: empty 2820 2821 2822 2823
bb: empty 2826 2827 2828 2829 # busybox
sh: empty 2832 2833 2834 2835 # bash POSIX mode
--
Dan Douglas
ent contexts. This will yield 0 for initial values of `a' between 1
and 4:
a=2; [[ 0 -ne --a" && "--a && --a -ne 0 ]] && let --a; echo $a
10 factorial (bash/ksh93/zsh):
$ f=n=n?n--*f:1 let n=10 f
$ echo "$n"
3628800
--
Dan Douglas
; DEBUG
$ [ <& $[ ] [ = [ && printf '%s\n' "$_ ...ha :)"
[ [ = [ 0<&$[ ]
[ ...ha :)
I like this. :)
6. Indirection combined with another modifier expands arrays to a single word.
$ a=({a..c}) b=a[@]; printf '<%s> ' "${!b}"; echo; printf '<%s> '
"${!b/%/foo}"; echo
I might have already reported this but can't find it. Ignore if so.
--
Dan Douglas
On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
> I can't speak to all your cases, but I had comments on a few:
>
> Dan Douglas wrote:
>
> > Most shells (and GCC) consider not grouping the assignment in a situation
> > like this an error. Bash toler
her script, then responsibility for
making that guarantee is inherited by the library consumer. There's no
difference.
To validate a "parameter name" fully requires a full shell parser, because the
subscript of an indexed array is effectively a part of its name as far as Bash
is concerned.
--
Dan Douglas
On Friday, June 14, 2013 06:02:15 AM Dan Douglas wrote:
> On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
> > > On 10 Jun 2013 14:15, "Chris F.A. Johnson" wrote:
> > > >It is not the least bit difficult with eval:
> > > >
> > >
On Friday, June 14, 2013 02:30:19 PM Pierre Gaston wrote:
> On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas wrote:
> > Also forgot to mention (though it should be obvious).
> >
> > $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo
while
[[ ${!1+_} ]] || return 1
typeset -a "__getElemArr=${!1}"
set -- "__getElemArr${1#*]}"
[[ $1 == *\[!(@]|\*]) ]]
do :
done
printf '<%s> ' "${!1}"
echo
}
a=( '(a b c)' $'([3]=\'(d e f)\' [5]=1 2 3)' '(g h i)' )
# typeset -a a=(([0]=a [1]=b [2]=c) ([3]=([0]=d [1]=e [2]=f) [5]=1 [6]=2 [7]=3)
([0]=g [1]=h [2]=i) )
getElem 'a[1][3][@]' || echo unset
--
Dan Douglas
expansion do not occur within the [[ keyword.
Where does it say that you can count on [[:alpha:]] being the same in non-POSIX
locales? I see it defined for the POSIX locale.
Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
not so sure it's actually better in practice. (talking about standard shell
pattern matching of course)
--
Dan Douglas
On Thu, Jun 20, 2013 at 7:09 AM, Greg Wooledge wrote:
> On Wed, Jun 19, 2013 at 06:12:57PM -0500, Dan Douglas wrote:
>> Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
>> not so sure it's actually better in practice. (talking about standard
This function (colorSet) takes one or more associative array names and
can populate it with a few predefined color palates. Written for
Bash/ksh93/zsh.
http://wiki.bash-hackers.org/snipplets/add_color_to_your_scripts
--
Dan Douglas
l text color.
>
> You can get around that by using read:
>
>
> read _CRST < <(tput sgr0) #Reset
> read _CRed < <(tput setaf 1) #Red
> read _CBLD < <(tput bold) #Bold
Can also give all the debug output %q formatting.
exec {BASH_XTRACEFD}> >(set +x; while IFS= read -r x; do printf %q\\n "$x";
done)
--
Dan Douglas
assigning the
values, which is why:
$ ( declare -ia foo=(1 2 xx 3); echo "${foo[@]}" )
1 2 xx 3
always gives you the xx, while forcing the evaluation to be done within
declare's environment gives a different result (e.g. with quotes):
$ ( declare -ia 'foo=(1 2 xx 3)'; echo "${foo[@]}" )
1 2 0 3
I think this was already known and not a bug, and doesn't have to do with the
order options are supplied in.
--
Dan Douglas
about this here over a year ago:
http://wiki.bash-hackers.org/syntax/arrays#integer_arrays
I think I even have some code that relies upon this effect.
--
Dan Douglas
quot; is still going to end up evaluating to whatever expression is stored in x.
If you want, you can force it to behave the other way as shown in my first
reply.
The primary reason I said it isn't a bug is because this has been discussed on
the list a few times before and that's been the general consensus.
--
Dan Douglas
become string assignments.
Same.
> 6. Indirection combined with another modifier expands arrays to a single
> word.
fixed.
:-)
--
Dan Douglas
ests should run in any shell provided
# you can supply all the necessary workarounds, and they correctly interpret
# ksh93 printf %q output (requires $'...'). At least one level of recursive
# arithmetic variable evaluation must also be supported.
# Dan Douglas
namespace main {
nsequenced]
int main() { int x=0; printf("%d\n", x+=x=1); return 0; }
~~ ^
1 warning generated.
2
--
Dan Douglas
On Sunday, August 04, 2013 12:30:48 AM Roland Mainz wrote:
> On Sun, Aug 4, 2013 at 12:04 AM, Dan Douglas wrote:
> > Is it specified what the value of x should be after this expression?
> >
> > x=0; : $((x+=x=1))
> >
> > Bash, ksh93, mksh, posh say 1. zsh, d
value}
((i = .sh.value))
}
((x[a] += x[b] = 1))
print result: $i
--
Dan Douglas
h variable,
the RHS fires before the LHS of the +=.
There's just no amount of mind-bending I can think of that could make
evaluating the += first produce anything other than an error.
--
Dan Douglas
RSION"
> 4.2.45(2)-release
>
> It also occurs in 4.2.45(1)-release and 3.2.51(1)-release.
This was this issue:
http://gnu-bash.2382.n7.nabble.com/More-fun-with-IFS-td11388.html
The assignments are all consistent in 4.3.
https://gist.github.com/ormaaj/6381747
--
Dan Douglas
-o and -a are for entertainment.
~ $ bash -c 'set -a; [ -o -a -o -a -o ]; echo $?'
1
~ $ mksh -c 'set -a; [ -o -a -o -a -o ]; echo $?'
0
~ $ bash -c '[ -o -a -o -a > -o -o ]; echo $?'
0
~ $ mksh -c 'o=1 [ -o -a -o -a -gt -o ]; echo $?'
0
--
Dan Douglas
POSIX mode. I don't have a strong
desire for this. A good editor should make normal comments painless enough.
--
Dan Douglas
On Saturday, April 06, 2013 03:48:55 AM Dan Douglas wrote:
> Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me
> think this test should say "no":
>
> x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi
>
Here's more data. Some perm
On Monday, October 07, 2013 10:21:06 AM Chet Ramey wrote:
> The subshell command is clearly part of the || compound command. The
> subshell `knows' that it is part of || and set -e has no effect. This
> example has been discussed before, on this list and the austin-group
> Posix list, and the bas
s exit='eval "$BASH_COMMAND"'
$ alias shutdown='eval $BASH_COMMAND\&{,}'
--
Dan Douglas
On Fri, Jan 17, 2014 at 8:07 AM, Greg Wooledge wrote:
> On Fri, Jan 17, 2014 at 08:53:07AM -0500, Chet Ramey wrote:
>> On 1/17/14 8:01 AM, Greg Wooledge wrote:
>> > I would expect [[ x =~ yx ]] to fail (return 1) every time.
>>
>> There is a question about the correct behavior when y == '\', since
On Fri, Mar 7, 2014 at 1:38 PM, Eduardo A. Bustamante López
wrote:
> WARNING: the codes given below cause the shell to enter an infinite
> loop.
>
>
> Both:
> dualbus@debian:~$ bash -Tc 'f(){ :; }; trap return RETURN; f'
> ^C
>
> and:
> dualbus@debian:~$ bash -c 'f(){ trap return RETURN; }; f'
> ^
" syntax. IMO it shouldn't even be
documented. It causes endless confusion but the reason it exists isn't clear.
There are other alternate syntaxes that are also discouraged, but undocumented,
such as the "for ((;;)) { ...; }" syntax.
--
Dan Douglas
#x27;t
care to make every script depend on it.
The -a/-A problem is definitely the most common and annoying of these though
and the -A would be very useful even if left undocumented or marked as
deprecated.
--
Dan Douglas
On Thu, Mar 27, 2014 at 3:16 AM, Dan Douglas wrote:
> I have such a function of course, but don't care to make every script depend
> on it.
Oh, and of course I'll still be using the wrapper. This is a feature for my
great grandchildren to use once Apple is out of business and the
I don't believe any shell can currently read nul-delimited input into
an array without looping. It's been suggested to add a delimiter to
mapfile. It looks like mapfile uses zgetline() to wrap around calls to
zread() and doesn't support any delimiter. read(1) on the other hand
uses one of the zread
On Thu, Mar 27, 2014 at 5:05 PM, Mike Frysinger wrote:
> thanks, i wasn't aware of that func. that seems like the easiest solution.
mapfile it awesome, but for getting find(1) results into an array you
should continue to use a read -rd '' loop. read -d is somewhat
portable, and mapfile does not
atures such as "read
-N" do, and most work directly involving the shell is with text not binary data.
--
Dan Douglas
Not sure we have enough info here. Have you tried "set -x" to see what's really
going on? Have you also confirmed that it isn't actually calling your script
and the script simply isn't functioning as expected?
--
Dan Douglas
;evil here"; }; dequote() { eval printf %s "$1" 2> /dev/null;
}; set -x; dequote "; evil" )
+ dequote '; evil'
+ eval printf %s '; evil'
evil here
--
Dan Douglas
ub.com/ormaaj/04923e11e8bdc27688ad#file-output
As you can see there isn't much rhyme or reason to the results, and
these tests take into account all the other differences that don't have
to do with exporting.
Test 1 exports a global then localizes it. Test 2 exports a local and
tests a local from a child scope. Test 3 tests exported namerefs.
--
Dan Douglas
h -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
<000001> <01>
(...and if everybody else follows suit, they won't be missed. Worked out
fine for ECMAScript5 strict.)
--
Dan Douglas
On Monday, May 05, 2014 09:37:27 AM Eric Blake wrote:
> On 05/05/2014 05:09 AM, Dan Douglas wrote:
> > Just a heads up on something I hadn't noticed: Bash (and dash) treat
> > octal literals in printf precision inconsistently (using glibc -- not
> > sure if it's a b
ized x in g should hide f's x even with no value.
function f { typeset x=set; g x; }
function g { typeset x; h x; }
function h { typeset -n ref=$1; echo "${ref-unset}"; }
f x # should print "unset"
--
Dan Douglas
"; echo "$y"
+ typeset -n x
+ x='_; y'
+ x=foo
+ typeset -p '_; y'
declare -- _; y="foo"
++ typeset -p '_; y'
+ eval 'declare -- _; y="foo"'
++ declare -- _
++ y=foo
+ echo foo
foo
--
Dan Douglas
73bd08 "function f {
typeset x; typeset -n x; x=y; }; f",
from_file=0x4dcc50 "-c", flags=4) at evalstring.c:367
#21 0x0041f6ee in run_one_command (command=0x7fffd5fe "function f {
typeset x; typeset -n x; x=y; }; f") at shell.c:1339
#22 0x0041e9e0 in main (argc=3, argv=0x7fffd108,
env=0x7fffd128) at shell.c:694
--
Dan Douglas
On Wednesday, May 07, 2014 10:04:11 AM Chet Ramey wrote:
> On 5/7/14, 2:10 AM, Dan Douglas wrote:
> > By "doesn't shadow" you mean that it _does_ hide the global right?
> > Localizing
> > a variable should cover up globals and variables in parent scopes even i
On Wednesday, May 07, 2014 10:58:42 AM Chet Ramey wrote:
> On 5/7/14, 10:21 AM, Dan Douglas wrote:
> > Another one to do with namerefs. :-)
> >
> > Looks like it's when the target of the ref is local to the same scope.
> >
> > $ gdb -q -ex 'run -c "
40513 20140514 20140515 20140516 20140517
20140518 20140519
$ ksh -c 'printf "%(%Y%m%d)T " "" -{1..9}\ days; echo'
20140510 20140511 20140512 20140513 20140514 20140515 20140516 20140517
20140518 20140519
--
Dan Douglas
On Saturday, May 10, 2014 03:31:05 PM Dan Douglas wrote:
> $ bash -c 'printf -v a "%(%s)T" -1; printf "%(%Y%m%d)T " "$a"
"${a[a+=60*60*24,0]"{0..8}"}"; echo'
> 20140510 20140511 20140512 20140513 20140514 20140515 2014
usage of
GNU factor(1) (or at least the silliest).
http://wiki.bash-hackers.org/syntax/expansion/brace#more_fun
--
Dan Douglas
uot; that programmers can't not depend on.
I disagree with Guido, as do many others. Though all the same arguments apply
in this case. I see no good reason for an arbitrary limit but I understand the
opposing view.
--
Dan Douglas
0m0.035s
user0m0.020s
sys 0m0.033s
$ time bash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
8308
real0m3.993s
user0m4.032s
sys 0m0.165s
--
Dan Douglas
bug
in ksh here.
# Bash is correct here AFAICT.
$ bash -c 'typeset -A a; i="\$(echo \\\")" a[\"]=1+1; echo "$((a[$i]))"'
2
# ksh93 fails this test:
$ ksh -c 'typeset -A a; i="\$(echo \\\")" a[\"]=1+1; echo "$((a[$i]))"'
ksh: syntax error at line 1: `end of file' unexpected
--
Dan Douglas
On Mon, Jun 9, 2014 at 7:51 PM, Dale R. Worley wrote:
> But if I add braces around the condition, 'time' is recognized:
That's not too surprising. That "!" is unaffected is. "if ! ! time :;
then ..." is an equivalent but working pipeline. "if time { :; };"
should also be valid but time isn't reco
On Tue, Jun 10, 2014 at 8:39 AM, Dale R. Worley wrote:
>> From: Dan Douglas
>>
>> On Mon, Jun 9, 2014 at 7:51 PM, Dale R. Worley wrote:
>> > But if I add braces around the condition, 'time' is recognized:
>>
>> That's not too surprisi
I've heard process substitutions considerably complicate parsing. zsh
and ksh93 are the only others that have process substitutions that I
know of, and zsh can't handle unbalanced parentheses in that situation
either.
$ zsh -c $'cat <(cat <<"EOF"\n(test)(foo\nEOF\n)'
zsh:4: parse error near `<(ca
On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote:
> Yes, since bash can parse the same construct without any problems if you
> use command substitution, it looks like a bug. I'll take a look.
It brings to mind all those unbalanced paren case..esac bugs that
affected every shell ever.
I suppose
sh eval or
alias workaround. Notice calling break from a function with a RETURN trap set
bypasses the trap if break results in jumping out of the function (Yes, I
tried that one long ago).
--
Dan Douglas
On Sunday, July 06, 2014 10:04:17 AM Dan Douglas wrote:
> Frustratingly I'm pretty sure there isn't even a possible hackish eval or
> alias workaround.
Haha nevermind. I guess Bash in non-POSIX mode expands an aliased "done"
keyword.
shopt -s expand_aliases
m ${BASH_SOURCE}!"' >~/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 substituti
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:
> >>>
> >>
On Wed, Jul 23, 2014 at 1:29 PM, Chet Ramey wrote:
> On 7/23/14, 3:20 AM, maik.lied...@sungard.com wrote:
>> hello,
>>
>> to change our scripts from ksh to bash we have problems with vars and
>> leading zeros.
>> how we can declare hrs and min?
>
> Greg offered several good suggestions to force b
r zsh
mode. (it's the very first difference I've ever noticed in zsh between bash
and ksh emulations.)
--
Dan Douglas
On Wednesday, July 23, 2014 05:44:25 PM Dan Douglas wrote:
> On Wednesday, July 23, 2014 05:02:42 PM Chet Ramey wrote:
> > ksh93 -c 'echo $(( 010 ))'
>
> Oh heh. Maybe a compile-time option or something I'm doing wrong... I always
> assumed it intentionally
ons. The part that describes how
that works moved to XRAT section 2.6.1. However the part that refers 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
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:
> > >
aration
and assignment separately, or use a temporary variable to store the status. For
set -e the former is the only option.
--
Dan Douglas
code in examples/functions/autoload.*. I believe it serves
mostly the same purpose as exported functions.
--
Dan Douglas
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
>
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 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 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 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/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/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 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/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 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 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, 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.
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 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; }; <() }; }
> >
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
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
(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
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
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
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
; 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
ode to either declare something twice in the same scope or rely upon a global
being in a particular state.
--
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
;${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
101 - 200 of 269 matches
Mail list logo
