[...]
checking for bits64_t... no
checking for ptrdiff_t... yes
checking whether stat file-mode macros are broken... no
checking whether #! works in shell scripts... ./configure: ./conftest:
/bin/cat: bad interpreter: No such file or directory
yes
checking whether the ctype macros accept non-asc
On Sat, Nov 6, 2010 at 6:12 AM, wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VE
On Mon, Nov 22, 2010 at 10:33 AM, Марк Коренберг wrote:
> in latest bash:
>
> suppose script:
>
> for i in "${filenam...@]}"; do
> echo "$i"
> done
>
> if malicious user give file name "-e", empty string will be emitted to
> stdout, but string "-e" should.
>
> It will be nice if I cat write
> e
On Sat, Nov 20, 2010 at 2:45 AM, john.ruckstuhl
wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight? If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 20
On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy wrote:
> Hello,
>
> With a simple script such as that below, bash can enter an infinite loop of
> eating memory until the system is rendered unusable:
>
> #!/bin/bash
> PATH=~
> infinitely-recurse
>
> Save this as infinitely-recurse in your home dire
On Fri, Dec 10, 2010 at 11:25 AM, Diggory Hardy wrote:
> On Thursday 09 December 2010 Pierre Gaston wrote:
>> On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy
>> wrote:
>> > Hello,
>> >
>> > With a simple script such as that below, bash can enter an infi
On Wed, Dec 29, 2010 at 12:44 PM, ali hagigat wrote:
> Dennis,
>
> Nice. Much appreciated
> What logic is it using you think when we use echo 'ppp'\''qqq'?
>
The logic is:
1) you need to close the quotes with '
2) concatenate a single quotes using another form of quoting for instance:
\' but "'"
On Fri, Dec 31, 2010 at 11:38 AM, wrote:
>Hello
>
> For regular arrays, we can get the list of keys by using the form
> ${!some_arr...@]}.
> But this just doesn’t work for associative arrays.
>
> ${!some_associative_arr...@]} is actually 0. Is that a bug ?
> Is there another way to get th
On Fri, Dec 31, 2010 at 11:56 AM, wrote:
> Ha. Indeed, if i use declare –A, it works.
>
>
>
> But why is bash letting me use foo[bar]=something in the first place, if I
> don’t declare foo as an associative array ?
>
> Maybe the bug’s here.
>
>
>
> D
>
>
>
It's because [ ] is an
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='$
uname output: Linux pgas-laptop
On Tue, Feb 8, 2011 at 7:38 AM, mauede wrote:
>
> If I type "qstat" on a terminal line I get the batch running process ID
> which is not the same as $!.
You are confusing bash's jobs with the jobs of the batch utilities,
they are 2 unrelated things
=~ \a. matches an a followed by any char
On Thu, Feb 17, 2011 at 4:35 PM, Clark J. Wang wrote:
> On Thu, Feb 17, 2011 at 9:20 PM, Andreas Schwab >wrote:
>
> > "Clark J. Wang" writes:
> >
> > > See following script output:
> > >
> > > bash-4.2# cat quoted-pattern.sh
> > > [[ .a == \.a* ]] && ec
On Thu, Feb 17, 2011 at 4:56 PM, Clark J. Wang wrote:
> On Thu, Feb 17, 2011 at 7:09 PM, Clark J. Wang wrote:
>
> > See following script output:
> >
> > bash-4.2# cat quoted-pattern.sh
> > [[ .a == \.a* ]] && echo 1 # not quoted
> > [[ aa =~ \.a* ]] && echo 2 # quoted
> >
> > [[ aa =~ \a. ]]
On Fri, Feb 18, 2011 at 12:17 PM, Clark J. Wang wrote:
> On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab >wrote:
>
> > Maarten Billemont writes:
> >
> > > Why are we escaping all word break characters? rm file:name and rm
> > file\:name are effectively identical, I'm not sure I see the need for
On Mon, Feb 21, 2011 at 10:12 AM, Clark J. Wang wrote:
> Tested with 4.2:
>
> bash-4.2# complete -b help
> bash-4.2# help co
> command compgen complete compopt continue
> bash-4.2#
>
> --
> Clark J. Wang
>
It's probably because:
$ type coproc
coproc is a shell keyword
likewise help tim do
On Fri, Feb 18, 2011 at 5:36 PM, Steffen Daode Nurpmeso <
sdao...@googlemail.com> wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i386
> OS: darwin10.0
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
> -DCONF_OSTYPE='darwin10
On Mon, Feb 21, 2011 at 11:13 AM, Marcel de Reuver wrote:
> In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if
> the week number is even.
> Only in week 08 the error is: bash: 08: value too great for base
> (error token is "08") the same in week 09, all others are Ok...
>
> GNU
On Tue, Feb 22, 2011 at 3:46 PM, Greg Wooledge wrote:
> On Fri, Feb 18, 2011 at 04:36:06PM +0100, Steffen Daode Nurpmeso wrote:
> > I am not a sophisticated shell programmer, but i really think this
> > time it's a shell fault.
>
> You think *what* is the shell's fault?
>
> > You may invoke the c
On Fri, May 20, 2011 at 10:31 AM, Linda Walsh wrote:
>
> It appears printf in bash doesn't support unicode
> characters in a couple of ways:
>
> 1) use of of the \u and \U escape sequences
> in the format string (16 and 32 bit Unicode values).
$ printf '%s: \u6444\n' $BASH_VERSION
4.2
On Wed, Jul 20, 2011 at 1:35 PM, Cédric Martínez Campos
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_6
On Mon, Jul 25, 2011 at 12:20 PM, Linda Walsh wrote:
>
>
>
> I got great help in learning about how to do the perl equiv of (var1,
> var2, var3)= (list) using read var1 var2 var3 <<<(list).
>
> I use it often to get back lists of values from subroutine calls, but with
> sometimes useful, and some
On Mon, Jul 25, 2011 at 8:33 PM, Linda Walsh wrote:
> Pierre Gaston wrote:
>> Since you are already using global variables, why not simply use a
>> couple more for the return values?
>>
> ---
> Because a subshell cannot access the global variables of the
>
On Sun, Aug 14, 2011 at 7:51 AM, Linda Walsh wrote:
>
>
>
> ` Dennis Williamson wrote:
>>
>> On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
>>
>>>
>>> I have to use 'indirect' syntax: ${!name}
>>> But that doesn't seem to play well with array syntax:
>>> ${#${!name}[*]} # bash: ${#${
On Sun, Aug 14, 2011 at 10:39 PM, Linda Walsh wrote:
>
>
>
> ` Pierre Gaston wrote:
>>
>> On Sun, Aug 14, 2011 at 7:51 AM, Linda Walsh wrote:
>>
>>>
>>> Dennis Williamson wrote:
>>>
>>>>
>>>> On Sat, Aug 13, 2011
On Mon, Aug 15, 2011 at 2:31 AM, Linda Walsh wrote:
>
>
> Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
> Pierre Gaston wrote:
>>
>> Linda:
>>
>>
>>>
>>> please show quote the section
>>> that shows using an variable
I don't use this but we often have question on irc (and from time to time here)
about indirect array reference, so I thought it might be worth mentionning
>From the example of http://mywiki.wooledge.org/BashFAQ/006
ref='x[$(touch evilfile; echo 0)]'
ls -l evilfile # No such file or directory
On Thu, Aug 18, 2011 at 6:46 AM, Linda Walsh wrote:
>
>
>
> ` Eric Blake wrote:
>>
>> On 08/15/2011 04:40 PM, Sam Steingold wrote:
* Andreas Schwab [2011-08-15 22:04:04 +0200]:
Sam Steingold writes:
>
> Cool. Now, what does this imply?
"For almost every purpo
On Thu, Aug 18, 2011 at 5:13 PM, Linda Walsh wrote:
>
>
>
> Pierre Gaston wrote:
>>
>> On Mon, Aug 15, 2011 at 2:31 AM, Linda Walsh wrote:
>>
>>>
>>> Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
>>> Pierre Gaston wrote:
&g
On Tue, Aug 23, 2011 at 4:42 PM, Steven W. Orr wrote:
> I made a decision to implement the require module written by Noah Friedman
> that comes in the examples part of the bash distro. This is the trick for
> implementing the provide / require functionality of features.
>
> I love it. It works gre
On Wed, Sep 7, 2011 at 7:43 AM, lina wrote:
> (...)
> I wish the fied 2 from file 2 arranged the same sequence as the field
> 2 of file 1.
>
> Thanks
>
> (...)
>
For very general scripting questions like these, prefer the comp.unix.shell
group, this list is primarily about bugs in bash.
On Tue, Oct 11, 2011 at 3:38 AM, Bill Gradwohl wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> when I typo a command, bash comes back with a command not found but
> hangs the terminal for way too long.
>
> How do I get rid of the delay. I want it to release the terminal
> immediately
();
add_unwind_protect (xfree, input_string);
}
at least blocking and unblocking ALRM around this seems to fix the crash.
Pierre
On Thu, Nov 17, 2011 at 6:22 PM, Chet Ramey wrote:
> On 11/16/11 7:13 AM, jens.schmid...@arcor.de wrote:
>> Hi,
>>
>> I have the following problem:
>>
>> (Environment or regular) variable FOO contains the path of existing
>> directory "/foo". When I have a file "/foo/bar" in that directory and w
On Sun, Nov 20, 2011 at 6:43 PM, Peng Yu wrote:
> Hi,
>
> I don't see if there is a way to directly modify $@. I know 'shift'.
> But I'm wondering if there is any other way to modify $@.
>
> ~$ 1=x
> -bash: 1=x: command not found
> ~$ @=(a b c)
> -bash: syntax error near unexpected token `a'
>
you
On Fri, Dec 2, 2011 at 8:24 AM, Peng Yu wrote:
> Hi,
>
> ~$ cat ../execute.sh
> #!/usr/bin/env bash
>
> echo "$@"
> "$@"
>
> $ ../execute.sh ls >/tmp/tmp.txt
> $ cat /tmp/tmp.txt #I don't want "ls" be in the file
> ls
> main.sh
>
> '>' will not work unless eval is used in execute.sh.
On Fri, Dec 2, 2011 at 2:01 AM, 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-pc-linux-gnu'
> -DC
On Sat, Dec 24, 2011 at 5:08 PM, Bill Gradwohl wrote:
> On Thu, Dec 22, 2011 at 5:34 PM, Thorsten Glaser wrote:
>
>> People complain about the readability of code enough already, and as
>> practice shows, things like [[ have been around and nobody uses them
>> anyway (often using just POSIX, but
On Tue, Jan 3, 2012 at 7:16 PM, wrote:
...
> So I propose we 'wreck the language' to allow me to do
> $ read @
> to set $@, same with 1, 2,.. * (almost the same as @).
>
Since you can use "read -a arr" to set arr[1] arr[2] ...etc it's not
that interesting
Setting the positional parameters is rea
On Thu, Jan 12, 2012 at 12:26 PM, Sarnath K - ERS, HCLTech
wrote:
> Hello Jonathan,
>
> Thanks for your inputs. I was able to created a super-restricted login.
> Here are a few things that I learnt during this process:
>
> 1. "vim" has a restricted mode called "rvim (or) vim -Z". This way, I can
On Thu, Jan 12, 2012 at 12:51 PM, Sarnath K - ERS, HCLTech
wrote:
> Oops.. It actually works! That's a great catch!
>
> I thought "redirection" is not supported in restricted mode though..!
> I just checked... It is mostly related to "output" re-direction.
>
> Hmm..I think I am going to tinker
On Wed, Jan 18, 2012 at 6:19 AM, Teika Kazura wrote:
>
> Hi. When you edit a running bash script, it's affected, so you
> shouldn't do that [1][2]. However, I heard[3] that if you delete the
> script itself from the filesystem, the original is remembered by bash,
> and it continues to run as-is (a
On Mon, Jan 23, 2012 at 11:47 AM, Ralf Goertz
wrote:
> Philip wrote:
>
>> Hi! Short question this time..
>>
>> $ echo '-e'
>> does not print -e
>>
>> $ echo '-e '
>> does print -e .
>
> By the way, neither -e nor -E are explained in the option section of
> „help echo“. Only -n is mentioned there.
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 enable infinite command history ?
>
> One simple suggestion I've seen online is to set HISTSIZE and
> HISTFILESIZE to a large number.
On Mon, Jan 30, 2012 at 9:02 PM, Linda Walsh wrote:
>
>
> DJ Mills wrote:
>
>>> 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 num
On Mon, Feb 27, 2012 at 6:44 AM, Davide Baldini
wrote:
> On 02/27/12 05:04, DJ Mills wrote:
>> Think of regular here-doc (with an unquoted word) as being treated the
>> same way as a double-quoted string
>
> Thank you Mills, of course I can understand it _now_, after having hit
> the problem, but
On Mon, Feb 27, 2012 at 2:50 PM, Steven W. Orr wrote:
> On 2/27/2012 1:26 AM, Pierre Gaston wrote:
>>
>> On Mon, Feb 27, 2012 at 6:44 AM, Davide Baldini
>> wrote:
>>>
>>> On 02/27/12 05:04, DJ Mills wrote:
>>>>
>>>> Think o
On Wed, Feb 29, 2012 at 3:30 PM, Greg Wooledge wrote:
> On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
>> How can one get the same behavior as before and look up files
>> relative to PATH regardless of them having a '/' in them?
>
> What? That sounds like it WAS a bug before, and yo
On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini <
stefano.lattar...@gmail.com> wrote:
> On 03/02/2012 02:50 AM, Chet Ramey wrote:
> > On 2/29/12 2:42 PM, Eric Blake wrote:
> >
> > In the middle of the histrionics and gibberish, we have the nugget of an
> > actual proposal (thanks, Eric):
> >
> >
On Thu, Mar 22, 2012 at 2:06 PM, Tim Dickson wrote:
> eg a script called test2 as follows
> #!/bin/bash
> echo "type in your name"
> read USERNAME
> echo "hello $USERNAME"
>
> called via the shell by typing
> ./test2
> is interactive, but $- special variable doe not indicate it is.
It's not
On Tue, Mar 27, 2012 at 3:00 PM, Joachim Schmitz
wrote:
> dennis.birkh...@rwth-aachen.de wrote:
> >
>>
>> Bash Version: 4.2
>> Patch Level: 24
>> Release Status: release
>
>
> Interesting, seems the announcements dor patches 21-24 have gotten lost?
>
> bye, Jojo
>
they were posted on the mailing l
On Sun, Apr 8, 2012 at 12:50 AM, Linda Walsh wrote:
>
>
> Mike Frysinger wrote:
>
>> On Saturday 07 April 2012 16:45:55 Linda Walsh wrote:
>>>
>>> Is it an accidental omission from the bash manpage?
>>
>>
>> it's in the man page. read the "Arithmetic Expansion" section.
>> -mike
>
>
>
>
> My
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 before, but I'm
> suddenly working on a script where someone else has.
On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh wrote:
>
>
> Dennis Williamson wrote:
>
> Aliases are intended for command line convenience. You should use
>> functions, which can be exported and are the correct thing to use in
>> scripts (and even from the command line).
>>
>> "For almost every pu
On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh wrote:
>
>
> Dennis Williamson wrote:
>
> Aliases are intended for command line convenience. You should use
>> functions, which can be exported and are the correct thing to use in
>> scripts (and even from the command line).
>>
>> "For almost every pu
On Sat, Apr 14, 2012 at 8:31 AM, Pierre Gaston wrote:
>
>
> On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh wrote:
>
>>
>>
>> Dennis Williamson wrote:
>>
>> Aliases are intended for command line convenience. You should use
>>> functions, which
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.
> I got the same result on GNU bash, version 4.1.2(1)-release
> (x
On Fri, May 25, 2012 at 6:05 AM, 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-pc-linux-gnu'
> -D
On Fri, Jun 1, 2012 at 11:53 AM, freD wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: powerpc
> OS: aix5.1
> Compiler: xlc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
> -DCONF_OSTYPE='aix5.1' -DCONF_MACHTYPE='powerpc-ibm-aix
> 5.1' -DCO
On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
> bash sources .bashrc even for some non-interactive shells.
>
> For example with
>
> echo \$- is $-
>
> in ~/.bashrc, and shell set to /bin/bash (bash 4.2.28)
>
> ssh -n -T localhost true
>
> produces the output
>
> $- is hBc
>
> I assume
On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote:
> On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston
> wrote:
>> On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
>>> bash sources .bashrc even for some non-interactive shells.
> ...
>> "Remote non login no
On Sat, Jun 2, 2012 at 8:55 PM, rac8006 wrote:
>
> Why can't I get a clean compile of bash4.1? I was building until I did a
> configure --enable_progcomp
> Now it fails with the three missing symbols tgoto , BC and UP. I've
> searched this site with no answers.
> Searched the web found referenc
On Sun, Jun 3, 2012 at 3:05 AM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>
>> On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote:
>>>
>>> On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston
>>> wrote:
>>>>
>>>> On Sat, Jun 2,
On Sun, Jun 3, 2012 at 11:02 AM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>>
>> In all your examples the shell will be called like: bash -c 'isatty 0
>> 2'. If you use a bash compiled with the above option you can add 'ps
>> -p$$ -ocmd'
On Thu, Jun 7, 2012 at 6:07 AM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>>
>> The only Bourne-family shell that can manipulate arrays whose names are
>> passed to a function is ksh93, with its "nameref" command. Bash has
>> nothing analogous to that yet.
>
> =
>
> I don't unders
On Thu, Jun 7, 2012 at 6:07 AM, Linda Walsh wrote:
>(no I haven't made it space/bracket...whatever proof...just a bit
> more work)
It's not just "a bit more work", there are many workarounds but it's not
really possible to make a really robust generic solution for assignment,
and in the end it ju
On Thu, Jun 7, 2012 at 12:27 PM, Dan Douglas wrote:
> On Thursday, June 07, 2012 10:01:51 AM Pierre Gaston wrote:
>> On Thu, Jun 7, 2012 at 6:07 AM, Linda Walsh wrote:
>> >(no I haven't made it space/bracket...whatever proof...just a bit
>> > more work)
>
On Sat, Jun 9, 2012 at 4:01 AM, Linda Walsh wrote:
> File1:
> sdf:
> Ishtar:/tmp> more sdf
> #!/bin/bash
>
> _prgpth="${0:?}"; _prg="${_prgpth##*}"; _prgdr="${_prgpth%/$_prg}"
> [[ -z $_prgdr || $_prg == $_prgdr ]] && $_prgdr="$PWD"
> export PATH="$_prgdr/lib:$_prgdr:$PATH"
> shopt -s expand_alias
On Sat, Jun 9, 2012 at 10:05 AM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>>
>>
>>> trap backtrace ERR
>>> set -T
>>>
>>
>> To sum up ". sdf2" is returning 1
>> Bash considers . to be a simple c
On Mon, Jun 11, 2012 at 10:59 AM, John Embretsen wrote:
> On 27 Feb 2011 18:18:24 -0500, Chet Ramey wrote:
>>> On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bug wrote:
>>> A workaround is fine but is the 4.2 behavior bug or not?
>>
>>It's a more-or-less unintended consequence of the requested change
On Mon, Jun 18, 2012 at 9:35 PM, Greg Wooledge wrote:
> On Mon, Jun 18, 2012 at 02:19:41PM +0100, Jacobo de Vera wrote:
>
>> Subject: Re: Arrays declared global in function and initialised in same line
>> are not visible outside of function
>
> I can't reproduce that problem:
Probably because yo
On Thu, Jul 12, 2012 at 8:09 PM, Ernesto Messina
wrote:
> Hello, I think I found an overflow bug. I got the follow C program:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> char a[10];
> int i;
>
> strcpy(a, argv[1]);
>
> return 0;
> }
>
> Compiling with: gcc pr
On Fri, Jul 13, 2012 at 3:46 AM, Dennis Williamson
wrote:
> On Thu, Jul 12, 2012 at 1:57 PM, DJ Mills wrote:
>> 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
>
On Fri, Aug 3, 2012 at 6:32 AM, Noah Spurrier 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-pc-linu
On Fri, Aug 17, 2012 at 10:19 AM, John Summerfield wrote:
(...)
> The man page for bash contains a para entitled ENVIRONMENT which doesn't
> mention arrays, leaving the reader to assume they are not different from
> other shell variables.
the BUGS section contains:
Array variables may not (yet) b
It seems BASH_XTRACEFD becomes special only if you assign it normally
but not if you do:
exec {BASH_XTRACEFD}>file
Not a real major problem and I don't use it everyday, but the
statement looks so nice :D
On Thu, Nov 22, 2012 at 9:15 PM, Chet Ramey wrote:
> On 11/16/12 10:47 AM, Sam Liddicott wrote:
> > Repeated executions of: { echo $fd ; } {fd}> /dev/null
> > will emit different numbers, indicating that fd is not closed when the
> > block completes.
>
> This is intentional. Having been given a
On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote:
> On 11/23/12 2:04 AM, Pierre Gaston wrote:
>
> > It seems rather counter intuitive that the fd is not closed after leaving
> > the block.
> > With the normal redirection the fd is only available inside the block
> &
On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston wrote:
>
>
> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote:
>
>> On 11/23/12 2:04 AM, Pierre Gaston wrote:
>>
>> > It seems rather counter intuitive that the fd is not closed after
>> leaving
>> >
On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey wrote:
> On 11/26/12 12:11 PM, Sam Liddicott wrote:
> > 3. there already exists simple and explicit way to get the supposed
> benefit
> > using the existing mechanism "exec"
>
> Not quite. You still have to pick the file descriptor you want to use wit
On Fri, Dec 7, 2012 at 12:52 PM, Orlob Martin (EXT) <
extern.martin.or...@esolutions.de> 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='
ou need a
bit more work to be fully safe though:
while IFS= read -rd ''; do . done < <(find ... -print0)
Pierre
PS: next time consider trimming your use case to avoid us avoid to search
for your problems.
On Fri, Jan 18, 2013 at 1:38 PM, Linus Swälas wrote:
> On Fri, Jan 18, 2013 at 6:57 AM, Pierre Gaston
> wrote:
>>
>> On Thu, Jan 17, 2013 at 4:24 PM, Linus Swälas
>> wrote:
>>>
>>> I have a similar problem to report as Fiedler Roman regarding read
On Sun, Jan 27, 2013 at 5:52 AM, John Kearney wrote:
> Am 27.01.2013 01:37, schrieb Clark WANG:
>> On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh wrote:
>>
>>> I noted on the bash man page that it says it will start in posix
>>> compliance mode when started as 'sh' (/bin/sh).
>>>
>>> What does that
On Tue, Feb 12, 2013 at 1:54 AM, wrote:
> With the script below, I'd expect any fd pointing to /dev/null to be
> closed when the second llfd() is executed. Surprisingly, fd 3 is closed,
> but fd 10 is now open, pointing to /dev/null, as if eval copied it instead
> of closing it. Is this a bug?
>
On Tue, Feb 12, 2013 at 6:07 PM, Matei David wrote:
> Ok, but I see the same behaviour when eval runs in a subshell:
>
> $ bash -c 'llfd () { echo "pid:$BASHPID" >&2; ls -l /proc/$BASHPID/fd/
> >&2; }; x=3; eval "exec $x>/dev/null"; llfd; echo | eval "llfd $x>&-"'
> [same output, fd 10 open, poin
I don't quite see the point of having gnu parallel discussed in the
bash reference manual.
http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
I don't argue that it can be a useful tool, but then you might as well
discuss sed awk grep make find etc..
Or even the ones not part of the
On Tue, Feb 26, 2013 at 3:03 AM, 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 Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus wrote:
> On 02/26/2013 02:03 AM, 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.
>
> which is not always correct. Use type bui
On Thu, Feb 28, 2013 at 7:09 PM, Andreas Schwab wrote:
> Bob Proulx writes:
>
>> I say that somewhat tongue-in-cheek myself. Because sourcing files
>> removes the abstraction barriers of a stacked child process and
>> actions there can persistently change the current shell. Not good as
>> a gen
On Mon, Mar 11, 2013 at 7:11 PM, Linda Walsh wrote:
> Pierre Gaston wrote:
>> On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus wrote:
>>> I think the line above will produce unspecified behavior.
>
>> Man bash says:
>> If this execution fails because the file is
On Tue, Mar 12, 2013 at 12:37 AM, Linda Walsh wrote:
> Pierre Gaston wrote:
>>>
>>>
>>> It is likely that the document is assuming you are running on
>>> a POSIX compliant system where all users use the same shell so there is
>>> o
On Sat, Mar 16, 2013 at 6:28 PM, Chris Down wrote:
> On 2013-03-16 12:13, Chet Ramey wrote:
>> > If it cannot be removed, then some people are using it with the false
>> > expectation that it provides some increased security. Better to get
>> > rid of that than have someone think it is worth the
On Sun, Mar 17, 2013 at 4:33 AM, Bruce Dawson
wrote:
> Thanks -- good to know that there is a fast and POSIX compliant method of
> doing this. I should have included my optimized counting loop -- it's what
> we switched to when we realized that $(expr) was a problem. Here it is now:
>
> # This cod
On Sun, Mar 17, 2013 at 5:58 PM, Bruce Dawson
wrote:
> The man page is clear that it is displaying the results of wait3(). However
> it doesn't mention that this means that sub-process startup time is not
> accounted for. That's what I feel should be clarified. Otherwise a CPU bound
> task may app
On Sun, Mar 17, 2013 at 9:07 PM, Bob Proulx wrote:
> Bruce Dawson wrote:
>> The man page is clear that it is displaying the results of wait3().
>
> Man page for time? You mean the time section of the man page for
> bash.
no
> If you are looking at the time man page then you are looking at
> the
On Tue, Mar 19, 2013 at 5:03 AM, Bruce Dawson
wrote:
> I'll give those a try.
>
> BTW, I just posted the blog post to share what I'd found. You can see it
> here:
>
> http://randomascii.wordpress.com/2013/03/18/counting-to-ten-on-linux/
>
> I hope it's accurate, and I do think it would be worth me
On Sat, Mar 23, 2013 at 3:15 AM, Linda A. Walsh wrote:
> In reading some suse startup code (*shiver*),
>
> I came across this construct
>
>
>
> func() {
> local comm ## command from /proc/$pid/stat
>
> for comm; do
> test -s comm || continue
> ppid = pidofproc $comm
> parents="${
On Fri, Mar 29, 2013 at 5:10 PM, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
>
> I meant to update your wiki about it but I forgot.
> I guess read uses gets not fread and tha
On Fri, Mar 29, 2013 at 5:18 PM, John Kearney wrote:
> Oh and FYI
> IFS=: read
> may change the global IFS on some shells I think.
> Mainly thinking of pdksh right now.
it seems ok on this netbsd machine:
PD KSH v5.2.14 99/07/13.2
IFS=f read
On Wed, Apr 3, 2013 at 11:03 AM, Chris Down wrote:
> On 2013-04-03 11:00, Nikolai Kondrashov wrote:
> > >>>It doesn't work because you are trying to redefine an existing
> > >>>readonly variable.
> > >>
> > >>Yes, but I'm explicitly redefining it locally, only for this function.
> > >>And this wo
1 - 100 of 358 matches
Mail list logo
