[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "here strings" and tmpfiles
From: |
Robert Elz |
Subject: |
Re: "here strings" and tmpfiles |
Date: |
Wed, 20 Mar 2019 07:49:34 +0700 |
Date: Tue, 19 Mar 2019 08:25:50 -0400
From: Greg Wooledge <wooledg@eeg.ccf.org>
Message-ID: <20190319122550.khv5jp66iobjoejn@eeg.ccf.org>
| Yes, just like here documents do. And have always done, in all shells.
That's not correct. There are shells that don't use files for here
docs. Any application that relies on stdin being seekable is broken
(unless it makes that happen for itself) - the most obvious example
which is not seekable is when stdin is a terminal.
The same applies to any other file descriptor which is opened when
an application is started.
POSIX (XCU section 2.7.4) explicitly says (of here docs):
It is unspecified whether the file descriptor is opened as a
regular file, a special file, or a pipe. Portable applications
cannot rely on the file descriptor being seekable (see XSH lseek( )).
Note: I am not suggesting bash should change - using files for here docs
is the way they were originally implemented (in the Bourne sh) (though it
had bugs, which could leave the files lying around in some cases).
However, using files for here docs makes here docs unusable in a shell
running in single user mode with no writable filesystems (whatever is
mounted is read only, until after file system checks are finished).
kre
Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/03/19
Re: "here strings" and tmpfiles,
Robert Elz <=
Re: "here strings" and tmpfiles, Chet Ramey, 2019/03/22
Re: "here strings" and tmpfiles, Chet Ramey, 2019/03/22