Notes |
(0004221)
eblake (manager)
2019-01-24 20:15
edited on: 2019-01-24 20:17
|
A shell may not be able to prove whether a file is a text file, but can easily filter out a number of non-text files with a short read() or two (any file that contains a NUL byte, any file that does not end in a newline, any file that does not contain a newline within LINE_MAX bytes) regardless of locale, as well as the converse (any file that starts with #! might be treated as a text file rather than a binary to pass to exec(), even though POSIX itself states that the use of #! is non-portable). You are also correct that a file can be a text file in one locale but a non-text file in another locale, based on whether byte sequences cause encoding errors in one locale but not the other.
Given that existing shells also have various other heuristics (such as any iscntrl() hits in the first 512 bytes) for deciding whether a regular file is unlikely to be executable as a shell script (although it does not necessarily make the file a non-text file). I'm not sure if the desired action is sufficient to permit what existing shells do.
|
|
(0004222)
shware_systems (reporter)
2019-01-24 21:39
|
Yes, but that easy filtering still the province of the invoked shell, as things are written, possibly to return 126 as exit code. This applies when the file exists but doesn't have the x bit set too. These will cause exec() to fail, but the shell is still expected to try and process it as a script. As far as the logical model goes, how I read it, what heuristics may be implemented are an adjunct to, not replacement for, the line-by-line evaluations of XCU 2.3 once the invoked shell finishes initializing.
What this change does is make it so regular files are always included for consideration, but with the "may bypass" wording allows other file types to be included too. While it would usually be silly for a platform to process the data representing a directory as a script, it shouldn't be impossible to attempt it if the internal format can be considered text also, similar to tar headers and the expectations for ar archives. If the underlying file system does say 'no, the inode fields are always binary encoded', big or little endian, then I'd expect the shell to bypass trying to process it because that's defined as being non-text for the file type. |
|
(0004227)
kre (reporter)
2019-01-25 01:35
|
I am not sure of the point of this discussion.
This relates to the proposed resolution of 1161 I believe?
In that, the shell is already required to find the file it
would exec (somehow) - whatever rules it follows in making
that decision are appropriate here do, and the description
of the -v option to the command command does not need to list
lots of special cases to make this be OK.
The problem with the resolution to 1161 is recorded in
note 4223 attached to that bug report. |
|
(0004228)
kre (reporter)
2019-01-25 01:57
|
If this issue really is simply about what 2.9.1 (really
2.9.1.1.1.e.i.b)says then I agree with Ed, nothing more
is needed than what is there "not a text file" covers all
that is needed - it certainly includes devices, directories,
etc - and also allows the shell to avoid attempting to
interpret whatever files it considers to not possibly be
script files.
That's a good thing - we do not need to be specific about
just which files it should attempt to run, and which it
should not (especially these days as the universal use of
#! means that any script can make itself guaranteed
executable, and so the shell can be much more conservative
about what files it attempts to run as a script when the
exec fails.) |
|