On Fri, Dec 22, 2017 at 1:39 PM, Kevin Layer wrote:
> The bug happens to me on
> GNU bash, version 4.1.2(2)-release (x86_64-redhat-linux-gnu)
> and
> GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.4.0)
>
> The script is attached, but the function in question is this:
>
> function debu
On Mon, Dec 18, 2017 at 11:25 AM, Eric Engstrom wrote:
> Dear Bash Maintainer(s),
>
> Bash's default /etc/bash.bashrc (on debian systems at least) blindly
> overwrites PS1 even if it's been set already. This makes it difficult
> to use sudo's abiltity to set PS1 via the SUDO_PS1 env var.
>
> Per
On Wed, Nov 22, 2017 at 9:00 AM, Peter & Kelly Passchier <
peterke...@passchier.net> wrote:
> On 11/22/2017 08:04 PM, Greg Wooledge wrote:
>
>> wooledg:~$ bash-4.2
>> wooledg:~$ var=$'foo\t\tbar'
>> wooledg:~$ cat <<< "$var"
>> foo bar
>>
>
> I think you are missing the point. He is cl
On Wed, Nov 8, 2017 at 6:04 AM, kalle wrote:
> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an output of `u=rwx,g=rx,o=rx'.
> Shouldn't umask -S also formulate the mask in a negative way, as does
> `umask'? Thus giving out `u=,g=w,o=w'?
>
> gr
On Thu, Nov 2, 2017 at 3:35 PM, Chet Ramey wrote:
>
> There is a special builtin in the devel branch version (EPOCHREALTIME) that
> gives you the epoch time with microsecond resolution. It will be in the
> next release.
>
>
Out of curiosity, is that functionality going to extend to printf '%(fmt)T
On Tue, Sep 12, 2017 at 9:20 PM, Eduardo Bustamante
wrote:
> On Tue, Sep 12, 2017 at 5:04 PM, Adam Danischewski
> wrote:
> [...]
> > Declaring a variable doesn't seem risky enough to eat up the return code.
> > Is there a reason for this? I doubt that it would break anything to
> change.
> > It'
On Wed, Aug 23, 2017 at 3:57 PM, Eric Blake wrote:
>
> Not just deprecated, but inherently ambiguous. There are situations
> where you CANNOT tell whether the user meant -a to mean the binary
> operator or a string being tested against, because POSIX (intentionally)
> does not specify enough pre
It's an arithmetic expression, 1 is true and 0 is false. This is not the
same as the exit status of a command
On Fri, Aug 18, 2017 at 11:59 AM, Pierre Gaston
wrote:
> On Fri, Aug 18, 2017 at 6:22 PM, vanou wrote:
>
> > Hello,
> >
> > I think, there is document bug related to 'for' compound comm
Holy crap there is some nasty stuff in that script.
You can try shopt -s checkwinsize to see if that helps
On Mon, Aug 14, 2017 at 9:06 AM, Ángel wrote:
> On 2017-08-10 Leon Klingele wrote:
> > Is this problem caused by bash?
> >
> Most likely, something done by fzf is not "completely right" as
On Thu, Jun 22, 2017 at 7:51 AM, Greg Wooledge wrote:
> On Wed, Jun 21, 2017 at 10:30:22PM -0400, Chet Ramey wrote:
>
> OK, going forward, I am officially considering any use of unquoted $*
> or $@ in a script to be a BUG, an invocation of undefined behavior,
> not acceptable, no excuses.
>
>
I t
Why not unalias -a instead of simply going for cp? That way you know for a
fact that nothing has been changed
On Thu, May 18, 2017 at 8:59 PM, Ángel wrote:
> I'm afraid you will have to rewrite the function just to get this
> slightly different result (maybe you can source again that section of
On Thu, Aug 29, 2013 at 2:54 PM, Greg Wooledge wrote:
> On Thu, Aug 29, 2013 at 12:57:22PM -0400, DJ Mills wrote:
> > On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills
> wrote:
> >
> > > When using a non-default IFS (a default IFS would trim them), a single
> > >
On Thu, Aug 29, 2013 at 2:38 PM, Dan Douglas wrote:
> On Thursday, August 29, 2013 01:03:20 PM DJ Mills wrote:
> > $(arr=(foo bar baz); IFS=:; str=${arr[*]}; echo "$str")
> > foo bar baz
> > $ (arr=(foo bar baz); IFS=:; str="${arr[*]}"; echo "$st
$(arr=(foo bar baz); IFS=:; str=${arr[*]}; echo "$str")
foo bar baz
$ (arr=(foo bar baz); IFS=:; str="${arr[*]}"; echo "$str")
foo:bar:baz
Note that the same thing does not occur for "$*":
$ (set -- foo bar baz; IFS=:; str=$*; echo "$str")
foo:bar:baz
$ (set -- foo bar baz; IFS=:; str="$*"; echo "
On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills wrote:
> When using a non-default IFS (a default IFS would trim them), a single
> empty trailing field is ignored for read -a.
>
> IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> &#
When using a non-default IFS (a default IFS would trim them), a single
empty trailing field is ignored for read -a.
IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:'); printf '<%s> '
"${arr[@]}"; echo
<>
I would expect the output to be:
<> <>
On Mon, Aug 26, 2013 at 9:36 PM, David Lehmann <
david.lehm...@alumni.rutgers.edu> wrote:
> My issue is that the resulting behavior in Exercise 1 does not make sense.
>
> The resulting value of i should have no bearing on the exit code. If the
> addition succeeded, the expression should return 0
On Tue, Aug 6, 2013 at 3:20 AM, Andreas Schwab wrote:
> DJ Mills writes:
>
> > I still don't see that;
>
> Go strictly from left to right.
>
>
It doesn't make any kind of logical sense to do so. Yes, then the "(x =
1)" would be evaluated
last, but h
On Sun, Aug 4, 2013 at 4:41 PM, Andreas Schwab wrote:
> Chris Down writes:
>
> x+=a is the same as x=x+a. Now replace a by (x=1) and it becomes
> obvious that 1 is a perfectly valid outcome.
>
>
I still don't see that; for one thing even with:
#include
int main(void) {
int x = 0;
printf("
On Sun, Aug 4, 2013 at 9:08 PM, Linda Walsh wrote:
>
>
> Chris Down wrote:
>
>> Yes, I agree, it becomes ambiguous when described in this fashion. I
>> think the
>> aesthetics of x+=y vs x=x+y are important here.
>>
>
> From the bash manpage, it would see that += is higher precedence
> than assig
On Wed, Jun 19, 2013 at 12:56 PM, Chris Down wrote:
> On 20 June 2013 00:43, Greg Wooledge wrote:
> > On Thu, Jun 20, 2013 at 12:39:56AM +0800, Chris Down wrote:
> >> On 20 June 2013 00:29, DJ Mills wrote:
> >> > wordsplitting and pathname expansion do not occu
On Wed, Jun 12, 2013 at 6:53 PM, Linda Walsh wrote:
> The trace looks aprolike this:
>
>> ./ifc#137(handle_bonding_ops)> (( 18>3 ))
>>> ./ifc#138(handle_bonding_ops)> [[ mode=balance-rr 0 =~
>>>
>>
>> ^([a-zA-Z][-a-zA-Z0-9_]+)=(.+)**[[:space:]]+[a-zA-Z][-a-zA-Z0-**9_]+=.+.*$
> ]]
>
>> ./ifc
On Mon, Jun 17, 2013 at 11:53 AM, Brooks Moses wrote:
>
> (When is bash 4.3 expected?)
>
> - Brooks
>
>
Whenever it's ready.
On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh wrote:
> Sorry, forgot:
> > bash --version
> GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu)
> > uname -a
> Linux Ishtar 3.7.6-Isht-Van #4 SMP PREEMPT Thu Feb 7 01:34:39 PST 2013
> x86_64
> x86_64 x86_64 GNU/Linux
> ---
> I just can see why
On Mon, Feb 25, 2013 at 8:03 PM, Linda Walsh wrote:
> My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
> Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
>
> I had the foll0wing script which acts differently based on
> whether or not it has a #!/bin
On Sun, Feb 17, 2013 at 4:54 PM, Chet Ramey wrote:
> On 2/16/13 9:57 AM, Chris Down wrote:
>
> > Count me also in favour of removal of this section. At best the entire
> > section needs a complete rewrite, but why on earth we have a whole
> section
> > dedicated to a nonstandard external tool is
On Tue, Feb 5, 2013 at 6:39 PM, Tiwo W. wrote:
> I have seen "read -d '' var" to read multi-line heredocs into
> shell variables. An empty argument to -d seemed to mean "read
> up to the end of input". And this is what it does.
>
>
In addition to all of the "don't use set
On Tue, Jan 22, 2013 at 1:45 PM, Andreas Schwab wrote:
> This is true, but not obviously so. If you have the rule "redirections
> are processed from left to right", then this looks like an outlier (if
> you treat the pipe as another kind of redirection).
>
>
And that's the issue, a pipe is *not*
On Tue, Jan 15, 2013 at 9:19 AM, Andreas Schwab wrote:
> I'd also suggest to simplify the synopsis.
>
> cd [-LPe] [dir]
>
> Andreas.
>
>
>
-e is only used with -P, so the current synopsis makes more sense and is
clearer, IMO.
DJ
On Mon, Jan 14, 2013 at 10:03 PM, douxin wrote:
> Hello:
> i am from China and i am working on investigating the difference
> between bash V4.2 and V4.1
>
> according to official log there is a new feature description
>
> "Posix mode shells no longer exit if a variable assignment err
On Fri, Jan 11, 2013 at 4:51 PM, Chet Ramey wrote:
> On 1/11/13 4:46 PM, DJ Mills wrote:
>
> > Will they still be updated on WINCH without checkwinsize, as well? And
> will
> > they be set by default, or continue to be unset in scripts unless set
> manually?
>
> Th
On Fri, Jan 11, 2013 at 4:43 PM, Chet Ramey wrote:
> On 1/11/13 4:13 PM, Greg Wooledge wrote:
> > shopt -s checkwinsize only works in interactive shells. However, this
> > is not mentioned in the manual.
>
> Yes, that's true. This was reported in June, and the development versions
> since then
On Sat, Dec 15, 2012 at 1:01 PM, gregrwm wrote:
> >> > echo !(??|foo|bar)
> >>
> >> precisely where i started this thread, !(??)
> >
> > +(??) and !(??) are completely different things. !(??) was never
> mentioned in the original question, and should work as expected.
>
> yow, truly, you're saying
On Fri, Dec 14, 2012 at 8:37 PM, gregrwm wrote:
> > echo !(??|foo|bar)
>
> precisely where i started this thread, !(??)
>
+(??) and !(??) are completely different things. !(??) was never mentioned
in the original question, and should work as expected.
On Thu, Dec 13, 2012 at 3:42 PM, Chet Ramey wrote:
> It's a race to see whether or not the coprocess exits and is reaped and
> cleaned up before wait executes. `false' is a very short-lived process,
> doesn't require an exec, and so I would expect the child to exit very
> quickly. The cleanup,
On Thu, Dec 13, 2012 at 8:58 PM, Dan Douglas wrote:
> So, +(??) actually matches strings with even length, while +(???) matches
> those with odd length. +(?) matches any string with at least one character,
> and any number of ?'s matches multiples of that length.
>
> $ ksh -c 'printf %R\\n \?'
>
On Thu, Dec 13, 2012 at 2:32 PM, Chet Ramey wrote:
> On 12/12/12 3:11 AM, Andreas Schwab wrote:
>
> >> To reproduce:
> >> if ! coproc false; then echo error1 >&2; fi; wait "$COPROC_PID" ||
> echo
> >> error2 >&2
> >
> > This has nothing to do with if but with ! which doesn't appear to work
On Tue, Dec 11, 2012 at 2:49 PM, Greg Wooledge wrote:
> Since coproc creates a background job, it doesn't really makes sense that
> the "coproc" command itself would know the exit status of the background
> job. It would have to wait for the background job to terminate first,
> which would defea
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/locale'
This is the expected behavior, and it's the same in any language with a
'++' syntax.
var++ is POST-incrementing, that means the '+1' happens AFTER the expansion.
If you want it to happen before, you need pre-incrementing. ++var.
On Fri, Dec 7, 2012 at 5:52 AM, Orlob Martin (EXT) <
extern.martin.o
On Thu, Dec 6, 2012 at 6:11 AM, Dan Douglas wrote:
>
> I don't like &> to begin with. It makes the already cryptic redirection
> syntax
> that beginners struggle to understand even more confusing by adding a
> pointless shortcut with a non-obvious meaning instead of just being
> explicit.
> If yo
On Mon, Oct 29, 2012 at 7:09 PM, wrote:
> 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-redhat-linux-gnu'
On Wed, Oct 17, 2012 at 2:56 PM, wrote:
> so this is my actual gol:
>
> change this loop ( which is working fine )
>
> for file in /weldgfs/p51/gius_urban/pop_urban/tl_2010_us_uac10/UA_tiff/*.tif
> ; do
> filename=`basename $file .tif`
> tile=${filename:3:6}
> echo processin $file
>
On Wed, Oct 17, 2012 at 1:52 PM, wrote:
>
> Sorry i was not clear,
>
> yes my purpose is
>
> " simply to avoid having a second file containing a bash script "
> but
>
> find . -maxdepth 1 -name '*.txt' -print0 | xargs -n 1 -P 10 bash -c 'echo
> "$1" '
>
> or
>
> ls '*.txt' | xargs -n 1 -P 1
On Wed, Oct 17, 2012 at 12:49 PM, wrote:
> Hi
> i'm using often xargs to run process in parallel
>
> ls *.txt | xargs -n 1 -P 10 bash myscript.sh
>
> where myscript.sh is (for examples of course is longer):
> echo $1
>
> i would like to perform the same operation using the EOF syntax and import
On Tue, Oct 16, 2012 at 1:26 PM, Francis Moreau wrote:
> Hi,
>
> Currently the description of the builtin trap isn't enough regarding
> the description of the EXIT signal spec, IMHO.
>
> It says: "If a SIGNAL_SPEC is EXIT (0) ARG is executed on exit from
> the shell.", and nothing more, unless I'm
On Mon, Oct 15, 2012 at 8:08 PM, DJ Mills wrote:
> while read -r attr state; do
> if [[ $shellopts = *:"$attr":* ]]; then
> set -o "$attr"
> else
> set +o "$attr"
> fi
> done < <(set -o)
Erm, correction, that won't
On Mon, Oct 15, 2012 at 5:18 PM, Nikolai Kondrashov
wrote:
> On 10/16/2012 12:08 AM, Greg Wooledge wrote:
>>
>> Sidestepping the direct question for a moment, you could use a temporary
>> file instead of a command substitution to store the output. Then there
>> would be no subshell involved.
>
>
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
On Fri, Sep 28, 2012 at 12:52 AM, wrote:
> [OT] Thanks for your work for the Bash project. I've just learned that you've
> been the main maintainer for a long time, so keep it up! :)
+1000 to that, bash makes my life so much easier and I doubt you get
enough thanks
On Thu, Sep 20, 2012 at 6:00 PM, Jakub Jankiewicz wrote:
> Hi,
>
> I don't know where to ask this or report a bug about it.
>
> I find an issue with Unicode characters (polish) using figlet
>
> $ figlet ó
>
> /\/|
> |/\/|__ /
> /_\ |_ \
> / _ \___/
> /_/ \_\
>
> ó is 243, I can call ord(
On Fri, Sep 14, 2012 at 1:49 AM, Marcel Giannelia wrote:
> I believe I've found an inconsistency in bash or its documentation.
>
> I know the fact that things like [a-c] are highly locale-dependent in
> bash (doesn't mean I have to like it, but there it is). Fine. I've
> learned to live with it.
On Sun, Jul 29, 2012 at 10:23 AM, Jason Vas Dias
wrote:
>
> function count_colons { IFS=':' ;v=($@); echo ${#v[@]}; }
>
>
count_colons() { local n=${*//[!:]}; printf '%s\n' "${#n}"; }
On Thu, Jul 12, 2012 at 2:19 PM, Dennis Williamson
wrote:
> s=łódź; echo "${s^^} ${s~~}"'
> łóDź ŁÓDŹ
>
> The to-upper and the undocumented toggle operators should produce
> identical output in this situation, but only the toggle works
> correctly.
>
> This is in en_US.UTF-8, but also reported in
On Tue, May 29, 2012 at 8:34 AM, John E. Malmberg wrote:
>
> On this platform, file names with $ in them tend to show up as they have
> special meaning.
>
> BASH-4.2$ echo *\$*
> GNV$BASH.DSF GNV$BASH.EXE GNV$BASH.MAP GNV$SHELL.C_FIRST GNV$VERSION.C_FIRST
> gnv$bash_startup.com gnv$main_wrapper gn
On Thu, May 3, 2012 at 2:53 AM, Pierre Gaston wrote:
> On Thu, May 3, 2012 at 9:34 AM, Pan ruochen wrote:
>> Hi All,
>>
>> Suddenly I found that ((i++)) is not supported on bash.
>> Just try the following simple case:
>> $i=0; ((i++)); echo $?
>> And the result is
>> 1
>> which means an error.
>>
On Thu, Apr 26, 2012 at 2:16 PM, Greg Wooledge wrote:
> If the goal is to see the contents of an array, I'd use one of these,
> depending on how much detail I need:
>
> printf '<%s> ' "${array[@]}"; echo
>
> declare -p array
>
Or i'd use the args function Greg has shown before:
args() { printf
On Wed, Apr 25, 2012 at 1:36 PM, Ted Okuzumi wrote:
> Please note that if I use a different command in the while loop it works.
>
> So instead of
> echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
>
> if I say:
> echo "$mydata" | while read -r line; do echo "$line" ; done
>
> The
On Mon, Apr 9, 2012 at 1:31 PM, Dan Stromberg wrote:
>
> What should be the behavior of the following?
>
> if cmd1
> then
> cmd2
> fi && if cmd3
> then
> cmd4
> fi
>
> I've not joined two if's with a short-circuit boolean before, but I'm
> suddenly working on a script where someone else has.
On Mon, Apr 9, 2012 at 1:40 PM, Pierre Gaston wrote:
> On Mon, Apr 9, 2012 at 8:31 PM, Dan Stromberg wrote:
>>
>> What should be the behavior of the following?
>>
>> if cmd1
>> then
>> cmd2
>> fi && if cmd3
>> then
>> cmd4
>> fi
>>
>> I've not joined two if's with a short-circuit boolean bef
On Wed, Mar 21, 2012 at 6:31 PM, suvayu ali wrote:
> Hello Andreas,
>
> On Wed, Mar 21, 2012 at 15:24, Andreas Marschke
> wrote:
>> it has come to my attention that bash is unexpectedly removing quotes
>> from parameters given to a script if read from within the
>> script. See attached shell-scri
On Wed, Mar 21, 2012 at 10:24 AM, Andreas Marschke
wrote:
> Dear Maintainers of bash,
>
> it has come to my attention that bash is unexpectedly removing quotes
> from parameters given to a script if read from within the
> script. See attached shell-script for a full explanation.
>
> --
> Cheers,
>
On Sun, Feb 26, 2012 at 10:11 PM, Dan Douglas wrote:
> On Monday, February 27, 2012 04:03:34 AM Davide Baldini wrote:
>> Is this expected? Standing at the debian's man bash, variables inside
>> 'here document' are supposed to expand with no special exceptions
>> and undergo word
On Tue, Jan 31, 2012 at 12:08 PM, Ivan Yosifov wrote:
> On Mon, 2012-01-30 at 20:16 +0200, Pierre Gaston wrote:
>> On Mon, Jan 30, 2012 at 8:01 PM, Ivan Yosifov wrote:
>> > Hi everyone,
>> >
>> > I got an admittedly basic question but I'm really at my wits' end with
>> > this.
>> >
>> > How do I
> How is `INTEGER' any clearer? Integer constants can be specified as octal
> or hex.
Well, ok. The quoted section from the man page specifies a decimal.
> OK. How about if that sentence began with `When specifying n, the
> digits greater ...'?
declare -i foo; foo=20#a2; echo "$foo"
202
[base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number.
On Mon, Jan 23, 2012 at 2:58 PM, Denis Melnikov wrote:
> Hi,
> after the following fragment of code named variable gets empty:
>
> ls | while read file ; do
> v=1
> break
> done
> echo $v
>
> Is it a bug or a feature?
> GNU bash, version 4.1.2(1)-release
>
> Denis
>
Pipelines create subshells.
On Sun, Jan 22, 2012 at 9:39 AM, tapczan wrote:
> 1.
> case "$-" in
> *i*) echo This shell is interactive ;;
> *) echo This shell is not interactive ;;
> esac
>
This is the correct way to test. What makes you say it's not working for you?
> This is really a help-bash question. Please send all follow-ups
> there.
This.
However, see:
http://mywiki.wooledge.org/BashFAQ/100
for a more in-depth look at different string manipulation techniques,
including that one.
DJ
On Wed, Dec 7, 2011 at 9:43 PM, Miles Bader wrote:
> I notice that recently the behavior of bash completion w/r/t
> environment variables has changed, in a realy annoying way:
>
> If one has an environment variable like:
>
> ls=/usr/local/src
>
> and then hit to complete the following comma
On Fri, Nov 18, 2011 at 2:59 PM, Bob Proulx wrote:
> Dallas Clement wrote:
>> Geir Hauge wrote:
>> > Add ''set -x'' at the start of the function and examine the output
>> > to see if it actually runs touch from PATH.
>>
>> The strace output is showing that the correct 'touch' is being executed.
>
On Fri, Nov 4, 2011 at 4:31 AM, Graham North wrote:
> Hi,
>
> There seems to be a bug in bash regex.
>
> It doesn't recognise the line start caret:
>
> --Commands:
> ONE="/fred"
> TWO="fred/"
> REGEX='^/'
> echo "$ONE $TWO $REGEX"
> [[ "$ONE" =~ "$REGEX" ]] && echo yes || echo no
> [[ "$TWO" =~ "$
On Tue, Oct 4, 2011 at 8:49 PM, s.pl...@juno.com wrote:
> From: steve
> To: bug-bash@gnu.org
> Subject: bug in date command
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i586
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYP
> Because a subshell cannot access the global variables of the
> parent.
>
A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
A sub process cannot, unless the variables are exported. It does not sound like
you need to do so here.
On Fri, May 27, 2011 at 3:45 PM, Greg Wooledge wrote:
> On Fri, May 27, 2011 at 12:35:12PM -0700, Jacoby Hickerson wrote:
> > When executing a test script using the #!/bin/sh interpreter line
> > the shell expansion for the last argument ${!#} is blank,
>
> Good. And now you know why you
A -0 option, or even an option to use a different field separator, would be
an
excellent feature for mapfile. Currently, of course, you can use:
while IFS= read -rd '' file; do array+=("$file"); done
mapfile is considerably faster, however, and I think this would be quite
handy.
On Fri, May 6, 2011 at 12:07 PM, Dirk wrote:
> Hi folks,
>
> I am going nuts trying to read the output of a mysql select statement into
> an array. I have consulted bashfaq and other sources and tried various
> approaches, but every jump was somewhat short, it seems.
>
> This is what I tried (ba
On Fri, May 6, 2011 at 12:00 PM, Greg Wooledge wrote:
> On Fri, May 06, 2011 at 11:50:34AM -0400, Chet Ramey wrote:
> > Eric suggested %q, and that works to a
> > certain degree, but you can also use
> >
> > printf '"%s" ' "${vals[@]}" ; echo
> >
> > and get the double-quoting you want.
>
> Fails
On Tue, May 3, 2011 at 10:41 PM, Jonathan Nieder wrote:
> Hi Rafael,
>
> Rafael Fernandez wrote:
>
> > set -- a b c d e f g h i j k l m n o p q r s t u v w x y z
> > i=1
> > eval echo '$'$i # outputs an expected 'a'
> > i=10
> > eval echo '$'$i
On Mon, May 2, 2011 at 9:23 AM, Bruno Cesar Ribas wrote:
> On Mon, May 02, 2011 at 08:41:23AM -0400, Greg Wooledge wrote:
> > On Sun, May 01, 2011 at 09:17:49PM -0500, Jonathan Nieder wrote:
> > > Hi,
> > >
> > > ri...@inf.ufpr.br wrote:
> > >
> > > > When running "echo [A-Z]*" , it shows all
On Tue, Apr 26, 2011 at 11:42 AM, Steven W. Orr wrote:
> GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu)
>
> I ran a program that was supposed to die with an error message that said:
>
> Invalid format: example: 2.103.269.28-1-3
>
> Instead, it died with:
>
> i -- Invalid format: ex
82 matches
Mail list logo
