On 11/24/20 8:30 AM, Léa Gris wrote:
> Should variables automatically created within arithmetic constructs have
> the integer flag implied?
No. There's no reason to do this. If you want an integer variable, declare
it as such beforehand.
--
``The lyf so short, the craft so long to lerne.'' - Cha
On Tue, Nov 24, 2020 at 02:30:36PM +0100, Léa Gris wrote:
> Should variables automatically created within arithmetic constructs have the
> integer flag implied?
No. Please, no. It's bad enough that the -i flag exists in the first
place, without it being randomly added to poor innocent variables.
On Wed, Jun 20, 2018 at 10:22 PM, George wrote:
>
> Personally I do think some method of handling arbitrary binary data in the
> shell would be a welcome addition (and I think zsh provides that - don't
> remember if ksh does)
>
Ksh93 has "typeset -b" which defines vars for binary data (actually
On Sun, 2018-05-20 at 04:56 +0200, Garreau, Alexandre wrote:
> On 2015-11-13 at 07:17, Greg Wooledge wrote:
> Actually in the most general case, where those output streams may
> contain NUL bytes, it requires two temp files, because you can't store
> arbitrary data streams in bash variables at all.
Chet Ramey wrote:
On 5/21/18 8:37 AM, Greg Wooledge wrote:
If you're looking for some deeper answer, like "Why did Stephen Bourne
write it this way back in 1977?" then I would hazard a guess along the
lines of "It is tightly coupled to the underlying C argument-passing
interface which uses
On 5/21/18 8:37 AM, Greg Wooledge wrote:
> If you're looking for some deeper answer, like "Why did Stephen Bourne
> write it this way back in 1977?" then I would hazard a guess along the
> lines of "It is tightly coupled to the underlying C argument-passing
> interface which uses NUL-terminated st
On Sun, May 20, 2018 at 04:56:48AM +0200, Garreau, Alexandre wrote:
> On 2015-11-13 at 07:17, Greg Wooledge wrote:
> > Actually in the most general case, where those output streams may
> > contain NUL bytes, it requires two temp files, because you can't store
> > arbitrary data streams in bash vari
On 3/15/18 10:30 PM, dtr@home.homenet wrote:
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
> Variables mistakenly declared as local and then set as global
> happen to be unset for the “nounset†option and known
> to “declare -p†at the
OK submitted https://github.com/scop/bash-completion/issues/173
On 11/5/17 10:37 AM, 積丹尼 Dan Jacobson wrote:
> $ $BRO #makes $BROWSER. Good!
> $ xargs $BRO #just beeps. Bad.
> Yes I have bash-completions installed but am not sure what is to blame.
It's bash-completion. You can easily check this yourself by temporarily
disabling programmable completion.
--
``
On 08/24/2011 10:07 AM, Sam Steingold wrote:
* Eric Blake [2011-08-24 09:31:45 -0600]:
f(){ echo a=$a b=$b c=$c ; }
f
a= b= c=
a=a b=b f
a=a b=b c=
f
a=a b=b c=
Which is indeed correct under the rules for POSIX
This sucks big time.
Such is life when dealing with shell portability.
So if
> * Eric Blake [2011-08-24 09:31:45 -0600]:
>> f(){ echo a=$a b=$b c=$c ; }
>> f
>> a= b= c=
>> a=a b=b f
>> a=a b=b c=
>> f
>> a=a b=b c=
>
> Which is indeed correct under the rules for POSIX
This sucks big time.
So if I want to bind a variable for an eval invocation and do this:
eval "`./lib
On 08/24/2011 09:24 AM, Sam Steingold wrote:
CYGWIN_NT-5.2-WOW64 sds 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
BASH_VERSION='4.1.10(4)-release'
at the bash prompt I observe this:
$ f(){ echo a=$a b=$b c=$c ; }
$ unset a b c
$ a=a b=b f
a=a b=b c=
$ f
a= b= c=
which I believe is correct (i.e.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to lacsap on 7/30/2007 6:11 AM:
> i have 2 scripts : example : toto.sh (main script) and toto.conf.sh
>
> toto.conf.sh :
>
...
> exit 0
If you want toto.conf.sh to be sourced as part of a larger script, you
should either use return or ju
14 matches
Mail list logo
