On Thu, Aug 27, 2020 at 05:26:46AM +0700, Robert Elz wrote:
> 28469 28469 xkbcomp CALL unlink(0x7f7fec7b)
> 28469 28469 xkbcomp NAMI "/dev/stdout"
> 28469 28469 xkbcomp RET unlink -1 errno 13 Permission denied
> 28469 28469 xkbcomp CALL open(0x7f7fec7b,0xa01,0x1b6)
> 28469
On Fri, Aug 28, 2020 at 08:00:30AM +, Gabriel Winkler wrote:
> # Causes error
> test=0
> ((test++))
> echo $?
> 1
> echo $test
> 1
https://mywiki.wooledge.org/BashFAQ/105
Exercise 1. And 2. And the whole rest of the page.
On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
> #!/bin/bash
>
> function Dummy() {
>
> local -n namerefArray="$1"
> local -a -i myArray=("${namerefArray[@]}")
>
> local -p
> }
>
> declare -a -i myArray=('1' '2' '3')
You've got a local variable with the same name as the global
On Fri, Aug 28, 2020 at 06:37:00PM +0300, Oğuz wrote:
> 28 Ağustos 2020 Cuma tarihinde Greg Wooledge yazdı:
> > func1() {
> > declare -n _func1_ref="$1"
> > local _func1_i
> > ...
> > }
> >
> This doesn't make the slightest sense.
On Fri, Aug 28, 2020 at 06:20:04PM +0200, Binarus wrote:
> However, the main question is why leaving away the -a and -i in the
> second script makes things work as expected.
I'll leave aside my usual rant about -i for now. Here's your original
code:
#!/bin/bash
function Dummy() {
local -n na
On Sun, Aug 30, 2020 at 12:24:03PM +0200, Binarus wrote:
> On 30.08.2020 02:59, Koichi Murase wrote:
> > * Another way is to copy to the local array only when the name is
> > different from `myArray':
> >
> > function Dummy {
> > [[ $1 == myArray ]] ||
> > eval "local -a myArray=(\"\
On Sat, Aug 29, 2020 at 03:25:44PM -0400, Bruce Lilly wrote:
> Unfortunately, because bash is GPL, I can't post the copyrighted script
> which is covered by a non-GPL license.
On the extremely slim chance that you are genuinely confused, and not
just a troll:
The GPL covers bash. The GPL does NO
On Tue, Sep 01, 2020 at 02:14:33AM -0700, almahdi wrote:
> How to get last commnda history line number purely & directly on bash script
> or prompt ?
>
> as it's pure & directly viable in PS1 env. var.
> PS1=`echo \!`
>
> confusingly bash 'mainstream' itself wasn't found way to do
unicorn:~$ x='
:~$ read -p 'What is your name? ' -e -i "$LOGNAME" -r name
What is your name? greg_
Where _ represents the cursor. The string "greg" is pre-populated
from the -i option, and can be backspaced or whatever.
On Sun, Sep 06, 2020 at 12:06:26PM -0700, L A Walsh wrote:
> On 2020/09/06 05:52, Oğuz wrote:
> > 6 Eylül 2020 Pazar tarihinde almahdi yazdı:
> >
> > > How slower find -exec repetitively calling bash -c'' for invoking a
> > > function
> > > inside, compare to pipe repeated
>
>
>How I re
On Sun, Sep 06, 2020 at 01:18:22PM -0700, L A Walsh wrote:
> > as it's pure & directly viable in PS1 env. var.
> > PS1=`echo \!`
> ---
> Doesn't work if you don't have '!' support (I generally found
> '!' more often did unwanted things, but I never used csh):
You're talking abuot csh-style history
On Wed, Sep 09, 2020 at 11:29:01AM -0700, L A Walsh wrote:
> On 9/8/2020 5:11 AM, Greg Wooledge wrote:
> > On Sun, Sep 06, 2020 at 01:18:22PM -0700, L A Walsh wrote:
> > > > as it's pure & directly viable in PS1 env. var.
> > > > PS1=`echo \!`
>
On Sun, Sep 13, 2020 at 11:59:45AM +0200, A M wrote:
> Feature request: Enable possibility of colored stderr output.
Not possible. Output does not "pass through" bash on the way to the
terminal. Bash is like a plumber or a switchboard operator. Bash just
screws all the pipes together, or plugs
On Mon, Sep 14, 2020 at 10:09:16PM +0700, Budi wrote:
> How to do a readline function execution inside bash script as mimic to
> actual key press ?
Please tell us what you're actually trying to do. It makes a huge
difference.
You said "script", so I guess you don't want to pre-populate the input
On Wed, Sep 30, 2020 at 09:12:30AM +0200, Michael Green wrote:
> seq 1 4 | xargs ./bash_bug
>
> BEGIN: bash_bug
> --
> #!/usr/bin/env bash
> . "exists_or_not"
> export A123456789012345="${BASH_ARGV[*]}"
> mkdir -p /tmp/foobar
> perl -E 'say "hello world"' 'f
On Fri, Oct 16, 2020 at 09:28:26AM -0400, Chet Ramey wrote:
> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
>
> > Also a warning hint in the manual page could
> > help users before enabling this feature :)
>
> I agree, and the manual page in the release will reflect bracketed paste's
> default sett
On Tue, Oct 20, 2020 at 04:57:36PM -0700, L A Walsh wrote:
>
>
> On 2020/10/20 01:29, Andreas Kusalananda Kähäri wrote:
> >
> > In bash 4.3+, I would manke your "ar" variable a name reference variable
> > instead:
> >
> > $ ar1=(1 2 3 44)
> > $ declare -n ar=ar1
> > $ echo "${#ar[@]}"
> > 4
> >
On Wed, Oct 21, 2020 at 04:48:39PM +0200, r...@beelaertsict.nl wrote:
> #!/bin/bash
> # test error in while clause
> #
> set -x
> up () {
> i=$(($i+1))
> [ $i -eq 5 ] && j=$(($j+1)) && i=0
> }
> while [ $i -ne 4 -o $j -ne 2 ]
> do
> if [ $i -eq 3 ]
> then
> up && continue
If
On Wed, Oct 28, 2020 at 05:11:42PM +, Rachel Alderman wrote:
> I've been made aware of a GNU Bash profile code execution vulnerability
> https://exchange.xforce.ibmcloud.com/vulnerabilities/173116 reported last
> December (2019-12-16)
This URL doesn't work without Javascript, and with Javasc
On Fri, Nov 06, 2020 at 02:07:36PM +0100, Edouard Thiel wrote:
> there is an error in the bash documentation:
> https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins
>
> In the 'declare' builtin, option '-n', last sentence:
> "The nameref attribute cannot be applied to array va
On Mon, Nov 09, 2020 at 05:27:38PM +0700, Robert Elz wrote:
> | What cannot be controlled is the exit value if the block is not executed
> | i.e. if the initial evaluation of the condition is false. In that case,
> | the exit value is always zero.
>
> That's what the standard says it has to
bash version 5.0.3(1)-release, Debian package 5.0-4, amd64.
Prompted by a discussion with someone in IRC.
unicorn:~$ key='$(date >&2)'
unicorn:~$ declare -A aa
unicorn:~$ aa[$key]=foo
unicorn:~$ echo "${aa[$key]}"
foo
unicorn:~$ [[ -v aa[$key] ]]
Mon Nov 9 18:17:30 EST 2020
bash: aa: bad array s
On Mon, Nov 16, 2020 at 08:37:05PM +0700, Robert Elz wrote:
> Dale's point, with which I agree, is that you shouldn't even be attempting
> using aliases for things like that. If there is some bug there, I don't
> care, and I doubt anyone else does either.
If a bug can actually be pinpointed and d
On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:
> or (to reproduce error):
> an_alias='res=() t=""
>for ci in "${!foo[@]}"; do \
Nice detective work there. I can confirm this in Debian's bash 5.0.3:
unicorn:~$ alias foo='a=() b=""
> for i in 1; do echo hi; done'
unicorn:~
On Tue, Nov 17, 2020 at 09:35:35AM +0100, Pierre Colombier via Bug reports for
the GNU Bourne Again SHell wrote:
> I'm not sure this is actually a bug since dash act the same way but
> it's quite unexpected for the average user
Agreed! The behavior of set -e is extremely surprising, and
On Mon, Nov 23, 2020 at 07:36:29PM +, Jetzer, Bill wrote:
> The prefix and postfix versions of the increment (++) and
> decrement (--) operators return a non-zero exist status when the varable's
> value is zero. This causes scripts to terminate if `set -e` is used
https://my
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, Nov 25, 2020 at 08:06:57AM +0700, Budi wrote:
> Can we validly write a line
>
> unset local a b c d e f g h i
>
> to mean: local a b c d e f g h i;unset a b c d e f g h i
No. And besides, you would want to unset *first*, right?
What are you actually trying to do here?
> if yes, how
On Wed, Nov 25, 2020 at 02:48:44PM +0100, Frans de Boer wrote:
> Addressing associative arrays with an array statement - like echo
> ${k["${a[x]}"] does not work.
That seems to work for me, after I fix your quoting. Using your example
variables:
unicorn:~$ declare -A k
unicorn:~$ declare -a a
On Tue, Dec 08, 2020 at 09:47:05AM +0100, Andreas Schwab wrote:
> On Dez 07 2020, Testing Purposes wrote:
>
> > From an integer standpoint, I know that 08 (with one leading zero) is the
> > same as 8.
>
> Nope, it is a syntax error.
In a bash math context or in C, 08 is indeed a syntax error, as
On Mon, Dec 07, 2020 at 05:02:35PM -0800, L A Walsh wrote:
> If I type in ( + are keypresses)
>
> if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi
>
> bash displays:
>
> if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
> ok
Bash doesn't "display" things. Your terminal displays
On Tue, Dec 08, 2020 at 09:07:33AM -0500, Chet Ramey wrote:
> On 12/7/20 8:02 PM, L A Walsh wrote:
>
> > The problem is that bash isn't displaying a 'tab' character where
> > one was typed.
>
> It's readline and redisplay. Readline expands tabs to spaces using an
> internal tab stop of 8. This al
On Tue, Dec 22, 2020 at 03:42:46PM +0800, ffvh gfff wrote:
> for i in $(cat ~/poc.txt);do echo $i;done
https://mywiki.wooledge.org/DontReadLinesWithFor
https://mywiki.wooledge.org/BashFAQ/001
https://mywiki.wooledge.org/BashPitfalls$pf1
On Tue, Dec 22, 2020 at 04:18:39PM +0800, ffvh gfff wrote:
> command line:
> cat poc.txt | while read i; do echo $i;done
> it can not read "\"
You forgot to use the -r option in your read command.
On Sun, Dec 27, 2020 at 08:02:49AM -0500, Eli Schwartz wrote:
> I'm not sure I understand the question?
My interpretation is that for an async *simple* command of the
form cmd args & where cmd cannot be executed at all (due to
lack of permissions, perhaps, or because the external program is
no
On Fri, Jan 01, 2021 at 10:02:26PM +0100, Ángel wrote:
> Yes. In fact, you can already do that using an interface exactly
> identical to file operations:
>
> # Store a string in shared memory with key 'foo'
> echo "Hello world" > foo
>
> # Read value of key foo
> var="$(
>
> You only need to us
On Mon, Jan 04, 2021 at 08:26:59AM -0500, Saint Michael wrote:
> In this case, how do I quickly increase the number stored in "foo"?
> the file has 1 as content, and I have a new value to add to it quickly.
> Is there an atomic way to read,add, write a value to "foo"?
Nope!
It's almost like b
On Mon, Jan 04, 2021 at 10:44:40AM -0500, Saint Michael wrote:
> can you point me to your FAQ?
https://mywiki.wooledge.org/BashFAQ/045
On Wed, Jan 06, 2021 at 05:16:26PM +0100, felix wrote:
> I use near same version, but can't reproduce:
>
> $ echo $BASH_VERSION
> 5.0.3(1)-release
>
> $ echo [0-1]
> [0-1]
You need to create a file named "1" in the working directory first.
For different results, you could create a file
On Mon, Jan 11, 2021 at 09:07:08AM -0500, Chet Ramey wrote:
> On 1/10/21 2:55 PM, Oğuz wrote:
>
> > If I don't know the key beforehand, like if I read it from a file or the
> > like, this becomes a security issue. That is my concern,
> > `assoc_expand_once' doesn't help in that situation.
>
> If
On Mon, Jan 11, 2021 at 03:50:40PM +0100, Léa Gris wrote:
> safe_arith_index=${x@Q}
> declare -p safe_arith_index
> > declare -- safe_arith_index="'y[\$(date >&2)0]'"
> (( aa[$safe_arith_index]++ ))
> declare -p aa
> > declare -Ai aa=(["y[\$(date >&2)0]"]="3" )
OK, that one has potential, since it
> > If you are reluctant to change semantics, how about a new parameter
> > transformation to quote values using `sh_single_quote'?
>
> Why, when @Q already exists?
It's often the case that the strings generated by bash are being
fed to some other shell, where $'...' doesn't work. Granted, you c
On Mon, Jan 11, 2021 at 08:07:58PM -0500, Henry Bent wrote:
> locale.c: In function 'set_default_locale':
> locale.c:94:3: error: 'local_shiftstates' undeclared (first use in this
> function)
>local_shiftstates = 0;
>^
[...]
>
> These were supposed to be locale_shiftstates, no?
Certainly
On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> $ declare -n b=a[0]
I can't see any documentation that supports the idea that this should
be allowed in the first place.
-n Give each name the nameref attribute, making it a name
reference to ano
On Wed, Jan 13, 2021 at 08:28:44PM +0200, Ilkka Virta wrote:
> On Wed, Jan 13, 2021 at 7:49 PM Greg Wooledge wrote:
> > On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> > > $ declare -n b=a[0]
> >
> > I can't see any documentation that supports the i
On Wed, Jan 13, 2021 at 08:50:45PM +0200, Ilkka Virta wrote:
>However, nameref variables can reference array variables and subscripted
> array variables.
Ah, that's in a different section of the man page. OK, I concede that
this is a bug, then.
I give up trying to quote appropriate context. Here's what bash 5.0
is doing:
unicorn:~$ echo "$PATH"
/home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
unicorn:~$ type moo
bash: type: moo: not found
unicorn:~$ echo "echo M" &
On Thu, Jan 14, 2021 at 07:16:12PM +0700, pepa65 wrote:
> On 14/01/2021 16.44, William Park wrote:
> > Then, I just use variable "rev" and that would be equivalent to
> > ${@:55:10}.
>
> So you could just do: rev=(${template[@]:55:10})
Needs more quotes.
On Tue, Jan 19, 2021 at 01:38:13PM +0300, Oğuz wrote:
> $ declare -n c=a[@]
"However, nameref variables can reference array variables and
subscripted array variables."
Is a[@] a "subscripted array variable"?
On Thu, Jan 21, 2021 at 10:27:54PM +0100, Mathias Steiger wrote:
> Suppose I wrote a simple script:
>
> {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo "no";
> fi } > output
I count at least 3 bugs here, or 4 if you run this from something that
works around the exec format
On Fri, Jan 22, 2021 at 10:11:58PM +0700, pepa65 wrote:
> I would like a "<<<" that doesn't cut off empty lines (perhaps "<<<-" ?)
What are you talking about? <<< does not remove anything. It only adds
a newline, which can admittedly be irritating in some situations.
unicorn:~$ cat <<< $'one\n\
On Sat, Jan 23, 2021 at 12:47:58AM +0700, pepa65 wrote:
> It is otherwise very hard to get command output into a variable without
> a subshell.
It's not hard at all. People just have a deep, almost religious, loathing
against creating their own temp files.
And yet, these same people are *perfect
On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote:
> 25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
> > declare -A copy
> > eval copy=( "${assoc[@]@K}" )
>
> So many reputable people contributed to the demonization of `eval' that I
> don't think I can convince anyone that there's nothing w
On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
> This is good advice. If the double-quoting the @K transformation performs
> is not what you need, use the @Q transformation to get something closer.
Those don't do the same thing, though.
unicorn:~$ declare -A aa=([a key]="a value" [$'
On Mon, Jan 25, 2021 at 08:58:23PM +0300, Oğuz wrote:
> This sentence alone reflects that article's perspective on the issue.
> > "eval" is a common misspelling of "evil".
>
> I rarely use eval, but when I do, it works just fine. I can't really agree
> with the sentiment of your article, sorry.
A
On Mon, Jan 25, 2021 at 02:46:24PM -0500, Chet Ramey wrote:
> On 1/25/21 12:58 PM, Oğuz wrote:
>
> > I rarely use eval, but when I do, it works just fine.
>
> Someone should create a meme with this text superimposed on an image of the
> Dos Equis most interesting man in the world.
https://imgfli
On Wed, Jan 27, 2021 at 09:21:09PM +0100, Alex fxmbsw7 Ratchev wrote:
> as well as one newline instead of x, it cuts afik _one_ ending nrwline, not
> all
If you mean command substitution, this is incorrect. Command substitution
removes all trailing newlines.
On Fri, Jan 29, 2021 at 12:33:17AM +0100, Jean-Jacques Brucker wrote:
> $ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd -r -p | base64) |
> tee >(xxd -r -p | basenc --base64url )
> dc30a6d79f3b47e310b8b9f5fbadba57
> 3DCm1587R+MQuLn1+626Vw==
> 3DCm1587R-MQuLn1-626Vz0Vhw==
Yes, there is a r
On Mon, Feb 01, 2021 at 04:34:17PM +0100, Alex fxmbsw7 Ratchev wrote:
> and as i wrote a couple of times, my .c skills are not sufficial in bug
> hunting to make a reproducer rather than main case
It has nothing to do with your skill level in C. Nobody expects you
to actually fix the bugs -- just
On Mon, Feb 15, 2021 at 12:27:42AM +0100, Daniel Gröber wrote:
> I've found what I belive to be a bug in how `test -v` expands the key in an
> associative array. The following minimal test case demonstrates the
> problem:
>
> declare -A array
>
> mytest () {
> array["$1"]=
On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote:
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Did you *install* the patched version so that it is the first "bash" in
your PATH before running this? If not, you should specify a path to
bash (e.g. ./bash -c
On Thu, Sep 25, 2014 at 07:58:56PM -0400, Chet Ramey wrote:
> We used to do that, and part of the code that I removed in patch 25
> supported the original `name()=() {'. We didn't use that very long; it
> turns out that the Bourne shell (and others, at that time) dumps core on
> malformed environm
On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote:
> Of course, their intention is precisely expressed by the '#!/bin/sh' header
Unfortunately, most people don't actually express an intent when they
use #!/bin/sh. They just copy some code from a random script they found
somewhere
On Fri, Sep 26, 2014 at 10:51:36AM -0400, Steve Simmons wrote:
> The more I see of how many bash-isms work when bash is invoked as /bin/sh,
> the more convinced I get that we need to either
>
> 1) make bash when invoked as /bin/sh fail those bash-isms
>
> 2) build a 'real' /bin/sh without those
On Fri, Sep 26, 2014 at 08:08:23PM +, Jay Freeman (saurik) wrote:
> Google's style guide for shell actually states that using :: in function
> names to separate library names from function names and package names within
> library names is their best practice.
My respect for Google just dropped
On Mon, Sep 29, 2014 at 05:11:52PM +0800, ??? wrote:
> /bin/echo: line 1: Mon: command not found
> make: *** [.build] Error 127
This is just a guess, but it looks like you tried to build bash in a
shell where you had previously been testing for shellshock-type
vulnerabilities, and you have a conta
On Mon, Oct 06, 2014 at 12:14:57PM -0700, Linda Walsh wrote:
>done <<<"$(get_net_IFnames_hwaddrs)"
> Where am I using a HERE doc?
<<< and << both create temporary files.
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[@]})
The redundant $(echo...) there is pretty bizarre. Then again, that
whole command is strange. You have a nice friendly arra
On Mon, Oct 06, 2014 at 02:00:47PM -0700, Linda Walsh wrote:
> How much of the original do you want?... wait... um...
> But the point it it should already work... I think it is trying to read
> from the network.
In the code below, you have a function that *generates* a stream of
data out of va
On Mon, Oct 06, 2014 at 04:04:25PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> >netdev_pat=... # (and other variable assignments)
> >(cd "$sysnet" &&
> >for ifname in ...; do
> >hwaddr=$(<"$ifname"/address)
> >act_hw2i
On Tue, Oct 07, 2014 at 09:54:21AM -0700, Linda Walsh wrote:
> Chet Ramey wrote:
> >It's syslog. Some vendors integrated patches that log all shell commands
> >to syslog.
> >
> No... that wasn't syslog, it was strace in another terminal where I attached
> the bacsh that was doing the various types
On Tue, Oct 07, 2014 at 10:45:53AM -0700, Linda Walsh wrote:
> I appreciate the options, but the option I want is the parent staying
> "put", and only sending children out to change dir's. Say some new
> version of init wants to isolate init processes by putting them in their
> own dir and t
On Tue, Oct 07, 2014 at 03:03:43PM -0700, Linda Walsh wrote:
> It's not thoroughly polished yet, but it does work. It can rename and
> reorder your
> network interfaces on boot so you can keep them with consistent names and
> ordering -- something systemd doesn't seem to support.
I don't know S
On Fri, Oct 10, 2014 at 02:00:41PM +, Nabia??ek, Wojciech wrote:
> Difference is in version number, mine is 4.3.30(3), your 4.3.30(2)
The number in parentheses is simply how many times Bash has been compiled
in the current source tree. If you apply a new patch and run "make"
again, the number
On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López wrote:
> On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com
> wrote:
> > variables with suffix "%%" can't be set/exported.
> > This makes problems restoring environments which where saved by external
On Fri, Oct 17, 2014 at 10:10:36AM -0400, Dave Kalaluhi wrote:
> Locally we are using:
>
> (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in
> {1..200} ; do echo done ; done) | bash ||
> echo "CVE-2014-7187 vulnerable, word_lineno"
As mentioned in previous emails on this topic, tha
> Von:Chet Ramey
> No, shell variable names should continue to be shell identifiers. You
> can already use `%' (any character, really) in environment variable
> names.
On Fri, Oct 17, 2014 at 05:22:30PM +0200, lorenz.bucher@rohde-schwarz.com
wrote:
> No, I can't.
> $ foo%%="bar"
> foo%
On Wed, Oct 22, 2014 at 10:20:04AM +0200, Hanno Böck wrote:
> export a='x'; echo "${a/x/~}"
>
> On bash 4.3 this will result in the user's homedir path. On 4.2 this
> will result in a ~.
> If one wants to get a "~" char there seems no easy portable way to do
> so. Using escaping with \~ works in 4
On Sun, Oct 26, 2014 at 09:10:32AM +0100, H.Merijn Brand wrote:
> 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some
> very small edits) but fails HP-UX 11.11, 11.00 and 10.20
Just for the record, I have never had any trouble building Bash
on HP-UX 10.20 using gcc 3.3. I suspect
On Wed, Oct 29, 2014 at 02:09:53PM +, Sami Kerola wrote:
> Would it make sense to add to 'time' builtin a way to measure how long
> a file descriptor is been kept open?
Doesn't really make much sense. If you want multiple independent timers,
there's no reason to tie them to open file descript
On Wed, Oct 29, 2014 at 09:58:59PM -0400, Marshall Giguere wrote:
> Submitting a shell script job to "at" either via pipe, or
> command line fails.
Since you're posting this to b...@packages.debian.org I will assume
you're running Debian. This bug/misfeature of "at" was fixed in
the Debian packag
On Wed, Nov 05, 2014 at 03:20:13PM +0100, Eric Blake wrote:
> On 11/05/2014 01:35 PM, Ian Jackson wrote:
> > Could there please be a new full tarball release of the patched
> > version ?
>
> There has never been a full tarball release of any other official patch;
There is a tarball of bash 3.2.48
On Thu, Nov 06, 2014 at 11:19:55AM +0100, Piotr Grzybowski wrote:
> would you accept a solution like this:
>
> 1. all running instances of bash with history support on, share
> history via shmem segment (some care as to its size should be taken)
> ...
As long as it is off by default. This is th
On Fri, Nov 14, 2014 at 06:01:37PM +0100, Piotr Grzybowski wrote:
> I would like to propose a patch, that allows to use \o in prompt:
>
> $ PS1="(\o)\u@\h \w $ "
> (himBH)merlin@ ~/bash $ set +hm
> (iBH)merlin@ ~/bash $
>
> \o gets replaced by all options that are on and visible via set
On Mon, Nov 17, 2014 at 04:30:07PM +0800, Jack wrote:
> As title, what difference between CVE-2014-7187 and CVE-2014-6278 ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7187 says
"Off-by-one error in the read_token_word function in parse.y"
So it's just another dumb parser bug, nothing
On Mon, Nov 17, 2014 at 04:22:53PM +, Stephane Chazelas wrote:
> The real bug doesn't have a CVE attached to it because it's not
> a vulnerability or bug. It was "allowing the bash parser to be
> exposed to untrusted data", more a very unsafe design that was
> allowing any minor bug to turn int
On Wed, Nov 19, 2014 at 04:20:51PM +, Jason Vas Dias wrote:
> Good day -
> Please could anyone explain why the first command below produces no output:
> $ ( declare -A a=([a]=1); if [ -v a ]; then echo yes; fi )
> $ ( declare -a a=([0]=1); if [ -v a ]; then echo yes; fi )
> yes
In a lot of
On Wed, Nov 19, 2014 at 07:59:42PM +, Jason Vas Dias wrote:
> [ ${#v[@] -gt 0 ] does not work
> if $v is a normal variable.
Doesn't it? It seems to work for me (once you fix the typo):
imadev:~$ unset v; v=''; test "${#v[@]}" -gt 0 && echo yes
yes
imadev:~$ unset v; v='x'; test "${#v[@]}" -
On Wed, Nov 19, 2014 at 02:41:13PM -0600, Eduardo A. Bustamante López wrote:
> People, are we forgetting that this is supposed to work in a function, by
> passing the name of a variable?
Passing the name of a variable has NEVER worked in ANY function for ANY
purpose in bash. It only works in ksh9
On Wed, Nov 19, 2014 at 09:52:39PM +0100, Piotr Grzybowski wrote:
> now I wonder, maybe this:
>
> $#a
>
> should return number of elements in array, if a is an array, and
> strlen($a) for scalars?
That would break existing scripts. $#a already means "argc followed by
the letter a".
If you mea
On Wed, Nov 19, 2014 at 09:59:38PM +0100, Piotr Grzybowski wrote:
> On Wed, Nov 19, 2014 at 9:56 PM, Greg Wooledge wrote:
> >
> > That would break existing scripts. $#a already means "argc followed by
> > the letter a".
> >
> > If you meant ${#a}
On Wed, Nov 19, 2014 at 10:32:52PM +0100, Piotr Grzybowski wrote:
> I do understand your point. Dont you understand the need to check in
> a simple (I know, nothing works, nothing is simple ;-)) way that given
> variable has value? no matter what it is?
No, I don't.
If I'm writing in C, and I wa
On Wed, Nov 19, 2014 at 11:05:51PM +0100, Piotr Grzybowski wrote:
> On Wed, Nov 19, 2014 at 10:51 PM, Eduardo A. Bustamante López
> wrote:
> > is_defined3() {
> > { declare -p -- "$1" && ! declare -fp -- "$1"; } 2>/dev/null >&2
> > }
>
> I dont know, but looks like a reusable code to me.
No
On Wed, Nov 19, 2014 at 11:22:48PM +0100, Piotr Grzybowski wrote:
> On Wed, Nov 19, 2014 at 11:16 PM, Greg Wooledge wrote:
> > So far, so good. But
> >
> > imadev:~$ foo() { echo foo; }
> > imadev:~$ foo=bar
> > imadev:~$ is_defined3 foo ; echo $?
>
On Fri, Nov 21, 2014 at 06:21:30AM +0800, konsolebox wrote:
> "eval" is not synonymous to security holes. There are many ways to sanitize
> it
> (if necessarily needed). Namerefs (declare -n in 4.3) and indirect variable
> references for example can avoid referencing invalid variable names simpl
On Fri, Nov 21, 2014 at 06:21:30AM +0800, konsolebox wrote:
> On Thu, Nov 20, 2014 at 4:47 AM, Greg Wooledge wrote:
> > Passing the name of a variable has NEVER worked in ANY function for ANY
> > purpose in bash.
>
> I hope you're actually not generalizing but you se
On Mon, Nov 24, 2014 at 10:52:30AM -0500, Steve Simmons wrote:
> My preference would be that the search order for any bash dotfiles are
> ~/.bash/file, then ~/.file. It's backwards-compatible, and for those of us
> who have $HOME in a single filesystem across many machines, a symbolic or
> hard lin
On Fri, Nov 28, 2014 at 10:25:52AM +0600, Sergei Tokaev wrote:
> Hi out there. Will it be good to add json support in bash internally. As
> in variable declarations: decalre "-j" "{"variable":"value"}"
This doesn't seem like an appropriate addition to bash, in my opinion.
Where do you draw the lin
On Tue, Dec 02, 2014 at 03:09:23PM +0545, bijay pant wrote:
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release
4.1.2 is vulnerable to shellshock. If you're going to compile from
source, you should compile a newer version with all the patches applied.
Patches for bash-4.1 are found in
On Wed, Dec 03, 2014 at 06:51:08PM +0400, Gennady Kupava wrote:
> That was quite unexpected for me as a user. I checked sed script like this:
> echo "a
> b"| sed '/a/!d'
>
> And that implementation detail were highly unexpected... What is the point
> of multiline edits if quotes are unreliable for
1401 - 1500 of 1972 matches
Mail list logo
