Mike Jakubik wrote:
> FYI.
This has been a known issue with bison-1.75 for over three years:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes
http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html
http://lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html
Chet
> Is it intentional that the following script, which worked in 2.05b now
> produces errors in 3.1:
>
> : `: "\\""`
>
> That now results in: unexpected EOF while looking for matching ``'
> Using a third backslash fixes it but this is inconsistent with ash bash2
> bsh ksh pdksh and zsh.
No, it is
Oliver Kiddle wrote:
> Is it intentional that the following script, which worked in 2.05b now
> produces errors in 3.1:
>
> : `: "\\""`
>
> That now results in: unexpected EOF while looking for matching ``'
> Using a third backslash fixes it but this is inconsistent with ash bash2
> bsh ksh pdksh
Phillip Susi wrote:
> Chet Ramey wrote:
>>> trap "cat $LOG > &3" ERR
>>> {
>>> foo
>>> bar
>>> } 3>&1 > /dev/null
>>
>> That's about right, but you need >&3 in the trap command.
>
> I did have > &3 in the trap command, see?
There can't be a space between `>' and `&'. That's a syntax error.
>
Paul Jarc ha scritto:
Francesco Montorsi <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED]:~$ kwrite &
=>[1] 20986
[EMAIL PROTECTED]:~$
=>[1]+ Donekwrite
[EMAIL PROTECTED]:~$
is there a way to tell bash not to print those lines marked with => ?
If you don't need to refer
Phillip Susi wrote:
> Does redirecting to /dev/tty work if the original stdout of the shell
> was NOT a tty? This script runs as a cron job so it has no tty.
Probably won't work to use /dev/tty in that case.
> Also is there a better way to save the original stdout and switch back
> to it than th
Thierry EXCOFFIER wrote:
> LINES and COLUMNS variables are not exported,
> so applications using these variables can not
> find the screen size.
The LINES and COLUMNS variables are an *override* to applications. It
is not an application's primary method of getting the size
Chet Ramey wrote:
trap "cat $LOG > &3" ERR
{
foo
bar
} 3>&1 > /dev/null
That's about right, but you need >&3 in the trap command.
I did have > &3 in the trap command, see?
I'm a bit worried though about hard coding the fd 3. Is there a way to get the
next available fd number and save it
Nicolas Rachinsky wrote:
> * Chet Ramey <[EMAIL PROTECTED]> [2006-03-05 12:38 -0500]:
>> This has been a known issue with bison-1.75 for over three years:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes
>> http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html
>>
Phillip Susi <[EMAIL PROTECTED]> wrote:
> Chet Ramey wrote:
>> That's about right, but you need >&3 in the trap command.
>
> I did have > &3 in the trap command, see?
You have "> &3". You need ">&3", without a space.
> I'm a bit worried though about hard coding the fd 3. Is there a way
> to get
Francesco Montorsi <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~$ kwrite &
> =>[1] 20986
> [EMAIL PROTECTED]:~$
> =>[1]+ Donekwrite
> [EMAIL PROTECTED]:~$
>
> is there a way to tell bash not to print those lines marked with => ?
If you don't need to refer to the proce
> This is how I interpreted POSIX's requirement that quoted strings
> inside backquotes be recursively processed:
My interpretation differs from yours, in order to match traditional behavior.
>
> "While processing the characters, if instances of expansions or quoting
> are found nested within th
12 matches
Mail list logo
