On 2/12/13 11:40 AM, Pierre Gaston wrote:
> 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 | e
On 12.02.2013 18:50, Dashing wrote:
On Tue, 12 Feb 2013 18:02:05 +0100 "Chet Ramey"
I've fixed the problem, and the fix will be in the next release.
Thank you, Chet!
On Tue, 12 Feb 2013 10:13:46 +0100 "Bernd Eggink"
superfluous blank in the ${rest: -1} expression
Bernd, this blank makes a
On Tue, Feb 12, 2013 at 04:22:08PM -0500, Matei David wrote:
> Generally speaking, it took me quite some time to figure out how to
> properly create a "double pipe" without using any intermediate files or
> fifos. The concept is very easy: in -> tee -> two parallel, independent
> pipes -> join -> o
On 2/12/13 2:07 PM, Matei David wrote:
OK. Let me try this again. One key to the explanations is that child
processes inherit all of the parent's open file descriptors.
> ... there seem to be not 2 but 3(!) types of file descriptors:
> 1. fds which are copied across both subshells and exec; like
Hi Chet,
Conceptually, the availability of a single flag "close-on-exec" (BTW, is
there a way to check those flags in bash or using /proc?) should create
only 2, not 3 types of file descriptors- that's what I find confusing. Does
subprocess creation as in '(llfd)' entail an execve() call? My guess
On 2/12/13 2:07 PM, Matei David wrote:
> ... there seem to be not 2 but 3(!) types of file descriptors:
> 1. fds which are copied across both subshells and exec; like 4
> 2. fds which are not copied across subshells; like 60&63
> 3. fds which are copied across subshells, but not exec; like 10
>
>
So in other words, you're saying I should use '... | eval "exec $x>&-;
llfd"' instead of '... | eval "llfd $x>&-"'. This way the subshell won't be
assuming I might use $x later. That works, but I still find it
counterintuitive that with the original syntax the subshell doesn't realize
there's nothi
On Tue, Feb 12, 2013 at 04:20:53AM -0800, laurent.tes...@gmail.com wrote:
> > liste=`ls *.T02`
This is broken because filenames may contain spaces, newlines, etc.
Use an array instead:
liste=(*.T02)
See http://mywiki.wooledge.org/BashPitfalls for an explanation of some
of the issues.
This type
On Tue, 12 Feb 2013 18:02:05 +0100 "Chet Ramey"
>I've fixed the problem, and the fix will be in the next release.
Thank you, Chet!
On Tue, 12 Feb 2013 10:13:46 +0100 "Bernd Eggink"
>superfluous blank in the ${rest: -1} expression
Bernd, this blank makes a big difference:
${rest: -1} last chara
Wow, thanks, I didn't know that. So this syntax achieves a bit more than I
asked for- it allows you to get a new unused file descriptor, right? It
seems that the only useful way to use a non-closing form (>&-, <&-) is with
exec, as in 'exec {new_fd}>&2'. (Why would I want the fd in a variable
other
Dear All,
I need to run a command that concat a list of files. It work like cat in UNIX.
teqc.exe file1 file2 ... > output
Then I want to build this list of file with bash, and insert it in a shell
script.
> liste=`ls *.T02`
> echo $liste
SHOB087k.T02 SHOB087l.T02 SHOB087m.T02 SHOB087n.T
On 11.02.2013 18:50, Dashing wrote:
Bash version: 4.2.042
I have a script that behaves erratically:
=
#! /bin/bash
last=${1##* }
rest=${1% *}
while [[ "${rest: -1}" == '\' ]]; do
last="${rest##* } $last"
oldrest=$rest
rest=${rest% *}
if [[ "$oldrest" == "$
> Bash version: 4.2.042
>
> I have a script that behaves erratically:
Thanks for the report. The reason it is erratic and not always
reproducible in the same spot is that it is the result of an array
bounds error, and so depends on the contents of memory beyond the
end of a string.
I've fixed
On 2/12/13 11:37 AM, Andreas Schwab wrote:
> Greg Wooledge writes:
>
>> Then you are still doing something wrong.
>
> No matter how badly the script is written, bash should execute it
> properly, which it doesn't. Try running it under valgrind in a
> multibyte locale and you will see the error
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
Greg Wooledge writes:
> Then you are still doing something wrong.
No matter how badly the script is written, bash should execute it
properly, which it doesn't. Try running it under valgrind in a
multibyte locale and you will see the error immediately:
==18677== Conditional jump or move depends
On Tue, Feb 12, 2013 at 11:07:06AM -0500, Matei David wrote:
> On a different but related note, I hate having to do eval to manipulate an
> fd stored in a variable. Why doesn't 'llfd $x>&-' work, especially since
> 'llfd >&$x' works just fine... so by the time >& is handled, the variable
> substitu
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, pointing to /dev/null, even though it's a
subshell]
$ bash -c 'llf
On Tue, 12 Feb 2013 14:45:26 +0100 "Greg Wooledge"
wrote:
>There are no literal backslashes in an argument that is
>produced by tab completion. The backslashes are a form
>of quoting, and they are removed by the calling shell
>during the quote removal phase.
When bind -x sets READLINE_LINE back
On Tue, Feb 12, 2013 at 02:37:03PM +0100, Dashing wrote:
> For my purposes this is irrelevant, because the nature of the
> script from which my example code derived is tab completion.
> READLINE_LINE will contain mplayer foo1\ foo2\ etc.
Then you are still doing something wrong.
imadev:~$ args
On Tue, 12 Feb 2013 14:16:24 +0100 "Greg Wooledge"
wrote:
>On Mon, Feb 11, 2013 at 06:50:49PM +0100, Dashing wrote:
>> $ ./pe 'mplayer foo1\ foo2\ foo3\ 4\ 5\ foo6\ 7'
>> :--Mistake--:
>> :--Mistake--:
>
>Whatever you're doing, it's wrong.
>
>./pe mplayer foo1\ foo2\ foo3\ 4\ 5\ foo6\ 7
>
>#!/bin
On Mon, Feb 11, 2013 at 06:50:49PM +0100, Dashing wrote:
> $ ./pe 'mplayer foo1\ foo2\ foo3\ 4\ 5\ foo6\ 7'
> :--Mistake--:
> :--Mistake--:
Whatever you're doing, it's wrong.
./pe mplayer foo1\ foo2\ foo3\ 4\ 5\ foo6\ 7
#!/bin/bash
prog=$1
shift
exec "$prog" extra args go here "$@"
THAT is how
22 matches
Mail list logo
