Re: [MiNT] Here documents and CRLF

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

On Fri, Jun 11, 1999 at 10:58:22AM +0200, Andreas Schwab wrote:
> "Guido Flohr" <gufl0000@stud.uni-sb.de> writes:
> 
> |> Hi!
> |> 
> |> I have made the following test with my stone-old Toswin (the hash `#' and
> |> the greater sign `>' are my shell prompts):
> |> 
> |> # UNIXMODE=/brUs
> |> # export UNIXMODE
> |> # cat >junk <<EOF
> |> > foo
> |> > bar
> |> > baz
> |> EOF
> |> # vi junk
> |> 
> |> In the vi it turns out that despite of the `b' in UNIXMODE the file junk
> |> contains carriage returns:
> |> 
> |> foo^M
> |> bar^M
> |> baz^M
> 
> Which is expected if your bash was started without UNIXMODE.  The temp

It was started with the correct UNIXMODE setting (I included the shell
commands only to make clear that it was set).  In fact I set UNIXMODE in
mint.cnf, n_aes.cnf and /etc/profile.  If I run `env' instead of `bash' in
TosWin I can see that UNIXMODE is set alright.

Furthermore: The bash that runs in the `virgin' terminal window behaves
alright.  Only after `login guido' things get messed up.  But my login
shell should actually inherit its environment from the parent process.

 > file for the here document was created by bash, and with CRLF,
since
> UNIXMODE wasn't set.  The cat command does not change this, since it runs
> in UNIXMODE semantics.  The only way to fix that is to make UNIXMODE a
> special variable for bash (which is easy).

I don't think that it is easy because I think that it has nothing to do
with the environment.  The facts are:

	- The problem does not arise with a shell running on the console.
	- The default terminal that TosWin provides is alright.
	- I suspected that turning echo on and off (as for password
	  input) may mess things up.  It doesn't, I've tested it.
	- A bash run as login shell on a pty has the buggy behavior no
 	  matter what UNIXMODE is set to.

So, what happens?  Whenever I hit the return key I actually send CRLF,
right?  I don't understand a lot about tty stuff but I think I remember
that it is a terminal attribute if the terminal should translate CRLF on
input into LF or not, isn't it?  Bash has most probably opened the input
file in `binary' mode, i. e. no translation takes place.  If CRLF appears
in the output file it is obvious that the shell has read CR from the tty
(resp. pty).

My suspicion is:  The kernel pty code is somehow broken (or bash is, very
unlikely).  When started as a login shell, bash will probably initialize
the terminal and if it is a pty then this initialization fails to some
extent.

Anyway, the problem is the input file mode, not the output file mode.  If
it was the output file mode then nine out of ten shell scripts would
produce garbage (here documents work perfectly from within scripts).

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de