A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1226 ====================================================================== Reported By: shware_systems Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1226 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Mark Ziegast Organization: SHware Systems Dev. User Reference: Section: XCU 2.9.1 Page Number: 2368 Line Number: 75592 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-01-24 19:00 UTC Last Modified: 2019-01-24 21:39 UTC ====================================================================== Summary: shell can not test if a file is text ======================================================================
---------------------------------------------------------------------- (0004222) shware_systems (reporter) - 2019-01-24 21:39 http://austingroupbugs.net/view.php?id=1226#c4222 ---------------------------------------------------------------------- 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. Issue History Date Modified Username Field Change ====================================================================== 2019-01-24 19:00 shware_systems New Issue 2019-01-24 19:00 shware_systems Name => Mark Ziegast 2019-01-24 19:00 shware_systems Organization => SHware Systems Dev. 2019-01-24 19:00 shware_systems Section => XCU 2.9.1 2019-01-24 19:00 shware_systems Page Number => 2368 2019-01-24 19:00 shware_systems Line Number => 75592 2019-01-24 20:15 eblake Note Added: 0004221 2019-01-24 20:17 eblake Note Edited: 0004221 2019-01-24 21:39 shware_systems Note Added: 0004222 ======================================================================
