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-
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
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.
> >
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:
>
> 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
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
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
[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
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.
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
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
12 matches
Mail list logo
