Hello,
as reported in [286861], certain expressions may confuse bash so that it is no
longer able to evaluate assignments.
[286861] https://bugzilla.redhat.com/show_bug.cgi?id=286861
I tried to debug it and found that if evalerror (thus longjmp) is called while
noeval != 0, it stays nonzero and
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2
-L/usr/src/packages/BUILD/bash-3.2/../readline-5.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYP
Horinius <[EMAIL PROTECTED]> wrote:
> Paul Jarc wrote:
>> Read entry E4 in the bash FAQ:
>> http://tiswww.case.edu/php/chet/bash/FAQ
>
> I've read several times that section but I'm not sure how to use the IFS.
IFS is only useful if you're splitting the fields of the line into
separate variables.
[EMAIL PROTECTED] wrote:
> ./doit: line 29: exec: 3: not found
>
> This is the line where i try to open the file descriptor
> for input:
> exec ${fd}<$inf
Try this:
eval "exec ${fd}< "'"$inf"'
And likewise, when closing the descriptor:
eval "exec ${fd}>&-"
paul
Paul Jarc wrote:
>
> Read entry E4 in the bash FAQ:
> http://tiswww.case.edu/php/chet/bash/FAQ
>
OK, I see, the problem comes from use of pipeline which triggers creation of
subprocess (why should they do so? -- no need to answer this question :p )
I've read several times that section but I'm
Paul Jarc wrote:
>
> If you're reading from a regular file, you can just eliminate the
> useless use of cat:
> while read line; do ...; done < test.txt
>
Oh yes! This is a lot better and syntactically simpler than using the file
descriptor 6 (which nevertheless is also a working solution).
I
Horinius <[EMAIL PROTECTED]> wrote:
> Is there any pitfall using this solution of yours? You talked about
> "regular file", what's that supposed to be? Text file vs binary file?
No, just that it doesn't work for pipes, so the data you're reading
has to be in a named file, not produced as the out
On Fri, 2 Nov 2007, Horinius wrote:
>
> It's a pity that the filename can't be put before the while loop or it'll be
> a lot easier to read, esp when the while loop is very big. (Once more, no
> need to answer to this comment of mine :p )
The while loop should never be very big. Functions and
Hugh Sasse wrote:
>
> On Fri, 2 Nov 2007, Horinius wrote:
>> I've found that if the last line isn't terminated by a new-line, that
>> line
>> can't be read. This seems to be a very common error and I've seen it in
>> other commands.
>
> This is a Unix convention. I don't know the origins.
>
On Fri, 2 Nov 2007, Horinius wrote:
>
>
>
> Hugh Sasse wrote:
> >
> > On Fri, 2 Nov 2007, Horinius wrote:
> >> I've found that if the last line isn't terminated by a new-line, that
> >> line
> >> can't be read. This seems to be a very common error and I've seen it in
> >> other commands.
> >
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2
-L/usr/src/packages/BUILD/bash-3.2/../readline-5.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
-DCONF_OSTYPE='linux-gnu' -DCONF_M
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.8
Compiler: gcc -m64
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8'
-DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/cs/bash-
12 matches
Mail list logo
