Re: Handling files with CRLF line ending

2022-12-07 Thread Chris Elvidge

On 06/12/2022 23:39, L A Walsh wrote:

On 2022/12/06 10:57, Chris Elvidge wrote:

Yair, how about using the Python installed in the WSL instance.

---
Oh, I wondered why Python used CRLF, but nothing else did.

What version of python are you using?  The Python for WSL,
the python for cygwin, or the python for Windows?  If you are
using python for Windows, I'd *sorta* expect it to use CRLF, but
would expect WSL or Cygwin versions to use just 'LF'.  Similarly w/bash --
I haven't tested it, but I'd expect bash compiled for windows
(using mingw toolchain) to use CRLF, but LF for WSL or Cygwin.

Are you using both tools for the same OS and subsys and having
them conflict?






I don't use Python generally, but my understanding of it (only a quick test)

f = open("demofile2.txt", "a")
f.write("Now the file has more content!")
f.close()

f.write doesn't append either \r\n or \n unless specified.

f.write("Now the file has more content!\n") does, in Windows, seem to 
append \r\n. In Linux (Slackware) and WSL (Slackware), it only appends \n.


So it does seem to be a "problem" with Windows rather than a problem 
with Python.


However, I may be wrong!!

Reading the file created in Python/Windows with bash read in linux:
read 

Re: Pending signal in EXIT trap causes pattern matching to fail

2022-12-07 Thread Andreas Schwab
On Okt 12 2022, Chet Ramey wrote:

> But that's not really the issue right here. The question is whether the
> shell should process additional terminating signals while it's running the
> exit trap from the terminating signal handler.

The problem is that the shell becomes uninterruptable while running the
exit trap.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."