Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Based on past experiences, I am assuming the e-mail this is a reply to was meant to be sent to the list and I am quoting it in full and replying on the list for that reason. On 10/03/2023 21:24, Robert Elz wrote: Date:Fri, 10 Mar 2023 18:13:00 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Other shells that exit are bosh, yash, and my own. It's both what POSIX | currently requires (contrary to what kre wrote on the bug) That's not how I intended what I wrote to be interpreted, I meant exactly what you said - when I wrote "most shells are doing what shells always have, and what the standard requires", I meant "exiting". I'm glad that that is what you meant. I wrote my mail before reading your mail where you said you tested something different, so when I read that you wrote that what most shells are doing is what the standard requires, it could only be interpreted to mean the opposite of what you intended. But as I wrote in my previous message, I was actually testing "command eval" rather than "command ." which I would normally expect to work about the same way in this regard, but it turns out that not shells all do. Further, and subsequent to when I sent that last message, I went and looked at my tests again - the way I do these is by (for tests like this one) composing a command line as input to one shell (each has its own xterm in my shell testing root window page - they're all tiled), then pasting it into the windows for all the others - then I can see the results from all of them, at the same time, and easily compare what happened (the command always starts $SHELL kind of like the example Geoff showed, except I do not quote that, because sometimes SHELL needs to be "bash -o posix" or similar, and I want that field split, not treated as a quoted word. For this, I tested both without, and with, "command" present ... but it turns out that somehow, for some of the shells, instead of running both tests, I managed to paste the wrong command, and ran the one without "command" twice, without noticing. That even included the NetBSD sh test, which contrary to what I said before, turns out does do the same thing for "." and "eval" in both cases (exit without command, not exit with it) which is what I had expected, before I saw the results of the incorrect test - before I noticed it was incorrect. | and what I think is probably the right thing for shells to do. I don't. I want to be able to source arbitrary script fragments, and eval arbitrary strings (there are no security issues here, the fragments and strings, are all provided by the user running the shell - anything that could be done buried one of those other ways, could simply be done as a command without subterfuge) without risking the shell exiting. Sometimes running them in a subshell works, but only sometimes. Sourcing arbitrary script fragments and having assurance that they do not exit the shell is not reasonable, as the arbitrary script fragment could contain an 'exit' command. In order to be able to do this, a subshell is needed. That will mean that variable assignments etc. do not persist in the parent shell, but that is unavoidable. Either the sourced script affects the parent shell, in which case it can cause the parent shell to exit, or it does not affect the parent shell. Beyond shell options and variable assignments not persisting in the parent shell, are there any other issues you see with running them in a subshell? | Whether bug 1629 should introduce a significant shell consistency issue | is not separate from bug 1629. Perhaps that one, and some new one, yet to be submitted, should be considered together, but resolving 1629 the right way should not be held hostage by other ancient weirdness that might not be so easy to alter. But perhaps after all, it might be - if it is only yash, bosh and your shell not already continuing after "command . file" fails because of a syntax error, then those might not matter, and those, plus, I think, mksh and ancient pdksh (and consequently, probably ksh88 as well) for "command eval 'gibberish<;)'" failing the same way then I'd guess mksh can get changed, and the others also no longer really matter. You have left out bash 4 here. For 'command eval', that version behaves the same way as for 'command .' in that it causes the shell to exit on syntax errors. | Bug 1629 started as trying to see what | shell authors are willing to implement. No, it started because read errors were not being handled in a rational way. A proposed solution depended upon what shell authors are willing to implement. True, I should have said "the discussion on bug 1629 started" rather than "bug 1629 started". | and I know bosh sadly isn't going to see an update anyway, Really? I thought some group of people had taken over Schilling's stuff. Whether they consider bosh worth continuing wi
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 21:33 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006201) chet_ramey (reporter) - 2023-03-10 21:33 https://www.austingroupbugs.net/view.php?id=1629#c6201 -- I'm going to change the bash behavior to exit immediately with status 128 on read errors while reading commands from a script. I'm going to hold off changing any other behavior. Bash already reads an entire `.' file before parsing and executing any commands in it, so that's not going to be a problem. I'd like to see the behavior of `command .' and `command eval' standardized so shells don't exit if the builtin fails, even with a read error, but I'm willing to have the discussion. Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 2023-03-10 14:52 kreNote Added: 0006200 2023-03-10 21:33 chet_ramey Note Added: 0006201 ==
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Date:Fri, 10 Mar 2023 18:13:00 + From:"Harald van Dijk via austin-group-l at The Open Group" Message-ID: | Other shells that exit are bosh, yash, and my own. It's both what POSIX | currently requires (contrary to what kre wrote on the bug) That's not how I intended what I wrote to be interpreted, I meant exactly what you said - when I wrote "most shells are doing what shells always have, and what the standard requires", I meant "exiting". But as I wrote in my previous message, I was actually testing "command eval" rather than "command ." which I would normally expect to work about the same way in this regard, but it turns out that not shells all do. Further, and subsequent to when I sent that last message, I went and looked at my tests again - the way I do these is by (for tests like this one) composing a command line as input to one shell (each has its own xterm in my shell testing root window page - they're all tiled), then pasting it into the windows for all the others - then I can see the results from all of them, at the same time, and easily compare what happened (the command always starts $SHELL kind of like the example Geoff showed, except I do not quote that, because sometimes SHELL needs to be "bash -o posix" or similar, and I want that field split, not treated as a quoted word. For this, I tested both without, and with, "command" present ... but it turns out that somehow, for some of the shells, instead of running both tests, I managed to paste the wrong command, and ran the one without "command" twice, without noticing. That even included the NetBSD sh test, which contrary to what I said before, turns out does do the same thing for "." and "eval" in both cases (exit without command, not exit with it) which is what I had expected, before I saw the results of the incorrect test - before I noticed it was incorrect. | and what I think is probably the right thing for shells to do. I don't. I want to be able to source arbitrary script fragments, and eval arbitrary strings (there are no security issues here, the fragments and strings, are all provided by the user running the shell - anything that could be done buried one of those other ways, could simply be done as a command without subterfuge) without risking the shell exiting. Sometimes running them in a subshell works, but only sometimes. | Whether bug 1629 should introduce a significant shell consistency issue | is not separate from bug 1629. Perhaps that one, and some new one, yet to be submitted, should be considered together, but resolving 1629 the right way should not be held hostage by other ancient weirdness that might not be so easy to alter. But perhaps after all, it might be - if it is only yash, bosh and your shell not already continuing after "command . file" fails because of a syntax error, then those might not matter, and those, plus, I think, mksh and ancient pdksh (and consequently, probably ksh88 as well) for "command eval 'gibberish<;)'" failing the same way then I'd guess mksh can get changed, and the others also no longer really matter. | Bug 1629 started as trying to see what | shell authors are willing to implement. No, it started because read errors were not being handled in a rational way. A proposed solution depended upon what shell authors are willing to implement. | and I know bosh sadly isn't going to see an update anyway, Really? I thought some group of people had taken over Schilling's stuff. Whether they consider bosh worth continuing with I am not sure (it still has more important issues than this remaining in it, and I don't believe is used much, if at all). | but I would hope that authors | of the other shells also have the good sense to implement something that | makes sense to them and keep it internally consistent, There is so much in the shell already which is not internally consistent, that one more thing (particularly in an area rarely seen) would hardly be noticed, but I very much doubt that there will not be at least an attempt to alter the "what happens when there's an error which is "shall exit" detected when running a special built-in as a sub-command of "command". Syntax errors aren't the only one, command eval 'shift 0 >/' is another (redirection errors are also "shall exit" when used with a special built-in as is being done here). I expect that will probably succeed, even if we all need to make some more changes to almost never encountered parts of the shell, and most probably it won't be "we all" in any case. kre
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
On 10/03/2023 17:12, Geoff Clare via austin-group-l at The Open Group wrote: -- (0006200) kre (reporter) - 2023-03-10 14:52 https://www.austingroupbugs.net/view.php?id=1629#c6200 -- Re https://www.austingroupbugs.net/view.php?id=1629#c6197 https://www.austingroupbugs.net/view.php?id=1629#c6198 https://www.austingroupbugs.net/view.php?id=1629#c6199 : I agree it is probably a problem that shells exit on syntax errors after "command ." (also "command eval") but it is a problem in the sense that it would be better if that isn't what happened - and it isn't just "some shells" that exit, it is most of them. None of the shells I tried exited. I used a file containing: foo < and ran: "$shell" -c 'command . ./file ; echo $?' All of bash, ksh88, ksh93, dash and mksh reported the syntax error and then executed the echo command (which output a non-zero number). For bash, it depends on the version. Version 4 will exit. Other shells that exit are bosh, yash, and my own. It's both what POSIX currently requires (contrary to what kre wrote on the bug) and what I think is probably the right thing for shells to do. In any case, this isn't a problem with the proposed resolution of this issue (read error behaviour) - a new bug needs to be filed and processed to get the behaviour of "command ." and "command eval" altered to be "not exit" (and for this, it may need to start out just being "may exit" rather than "shall not exit" with a future directions indicating that the stronger form will apply in a later version. I agree this should be handled as a separate issue, hence my replying by email instead of a note in the bug. Whether bug 1629 should introduce a significant shell consistency issue is not separate from bug 1629. Bug 1629 started as trying to see what shell authors are willing to implement. In that case, let me be clear, as it stands this is not something I am going to implement as written. I know you have no reason to care what I do in my shell, and I know bosh sadly isn't going to see an update anyway, but I would hope that authors of the other shells also have the good sense to implement something that makes sense to them and keep it internally consistent, whether that is by ignoring what 1629 specifies, or by ignoring what is required for syntax errors. There are more issues that make me doubt this is going to be implemented as written in other shells too, but that's for the other authors to raise. Cheers, Harald van Dijk
Re: Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
Date:Fri, 10 Mar 2023 17:12:50 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: | All of bash, ksh88, ksh93, dash and mksh reported the syntax error and | then executed the echo command (which output a non-zero number). yash and bosh don't, they simply exit. But you caught me ... the tests I did yesterday were of "command eval" which I assumed would be treated the same (I see no reason why there should be a difference), but apparently isn't in many shells (including the NetBSD one). kre
Syntax error with "command . file" (was: [1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script)
> -- > (0006200) kre (reporter) - 2023-03-10 14:52 > https://www.austingroupbugs.net/view.php?id=1629#c6200 > -- > Re https://www.austingroupbugs.net/view.php?id=1629#c6197 > https://www.austingroupbugs.net/view.php?id=1629#c6198 > https://www.austingroupbugs.net/view.php?id=1629#c6199 : > > I agree it is probably a problem that shells exit on syntax errors after > "command ." (also "command eval") but it is a problem in the sense that > it would be better if that isn't what happened - and it isn't just "some > shells" that exit, it is most of them. None of the shells I tried exited. I used a file containing: foo < and ran: "$shell" -c 'command . ./file ; echo $?' All of bash, ksh88, ksh93, dash and mksh reported the syntax error and then executed the echo command (which output a non-zero number). > In any case, this isn't a problem with the proposed resolution of this > issue (read error behaviour) - a new bug needs to be filed and processed > to get the behaviour of "command ." and "command eval" altered to be > "not exit" (and for this, it may need to start out just being "may exit" > rather than "shall not exit" with a future directions indicating that the > stronger form will apply in a later version. I agree this should be handled as a separate issue, hence my replying by email instead of a note in the bug. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 14:52 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006200) kre (reporter) - 2023-03-10 14:52 https://www.austingroupbugs.net/view.php?id=1629#c6200 -- Re https://www.austingroupbugs.net/view.php?id=1629#c6197 https://www.austingroupbugs.net/view.php?id=1629#c6198 https://www.austingroupbugs.net/view.php?id=1629#c6199 : I agree it is probably a problem that shells exit on syntax errors after "command ." (also "command eval") but it is a problem in the sense that it would be better if that isn't what happened - and it isn't just "some shells" that exit, it is most of them. I also agree it would be better for syntax errors and read errors to be treated the same for this. That is where we get a problem - read error requirements are new, and we can more or less do what we like, since everyone has more or less agreed that "treat it like EOF" which just about everyone did is not the right thing to do, and shells are going to have to change anyway. But for syntax errors, most shells are doing what shells always have, and what the standard requires - there even might be applications depending upon this behaviour (though I don't think I have seen many "command eval" and even less, if any "command ." in real scripts - and bash and zsh don't bother exiting (bash in non-posix mode anyway) even without "command" so probably there aren't applications that will care, but we cannot know. In any case, this isn't a problem with the proposed resolution of this issue (read error behaviour) - a new bug needs to be filed and processed to get the behaviour of "command ." and "command eval" altered to be "not exit" (and for this, it may need to start out just being "may exit" rather than "shall not exit" with a future directions indicating that the stronger form will apply in a later version. Incidentally, it appears there is no way to prevent a shell from exiting on a syntax error in a trap command string (action) - those are run "in a matter equivalent to eval action" which must include in the interpretation, as if by a special builtin, so if there is a failure to parse the action, the shell is currently required to exit (non-interactive shells) which is probably sub-optimal. (I haven't yet tested to see what shells actually do for this). Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project O
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 10:57 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006199) hvd (reporter) - 2023-03-10 10:57 https://austingroupbugs.net/view.php?id=1629#c6199 -- > True, and this is a defect for the syntax error case, as existing shells do not exit. Some existing shells do not exit. Others do. > It requires 128, not 126. Apologies, I noticed the change to require a specific exit status and not that it had been changed from 126. Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 2023-03-10 10:57 hvdNote Added: 0006199 ==
[Issue 8 drafts 0001631]: Default archive rules are incompatible with parallel processing.
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1631 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1631 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Applied Name: Dmitry Goncharov Organization: User Reference: Section:make Page Number: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/nframe.html Line Number:0 Final Accepted Text:See https://austingroupbugs.net/view.php?id=1631#c6169 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-01-21 18:45 UTC Last Modified: 2023-03-10 10:53 UTC == Summary:Default archive rules are incompatible with parallel processing. == Issue History Date ModifiedUsername FieldChange == 2023-01-21 18:45 dmitry_goncharovNew Issue 2023-01-21 18:45 dmitry_goncharovName => Dmitry Goncharov 2023-01-21 18:45 dmitry_goncharovSection => make 2023-01-21 18:45 dmitry_goncharovPage Number => https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/nframe.html 2023-01-21 18:45 dmitry_goncharovLine Number => 0 2023-01-21 21:48 kreNote Added: 0006124 2023-01-21 22:10 rillig Note Added: 0006125 2023-01-22 02:08 dmitry_goncharovNote Added: 0006126 2023-01-22 03:02 dmitry_goncharovNote Added: 0006127 2023-01-22 03:13 dmitry_goncharovNote Edited: 0006127 2023-01-22 03:13 dmitry_goncharovNote Edited: 0006127 2023-01-22 18:42 psmith Note Added: 0006128 2023-01-23 21:59 steffenNote Added: 0006131 2023-01-23 22:02 steffenNote Added: 0006132 2023-01-23 22:04 steffenNote Added: 0006133 2023-01-23 22:11 hvdNote Added: 0006134 2023-01-24 02:24 dmitry_goncharovNote Added: 0006135 2023-01-24 09:56 hvdNote Added: 0006136 2023-01-24 18:55 psmith Note Added: 0006137 2023-02-16 17:05 shware_systems Note Added: 0006152 2023-02-16 20:41 steffenNote Added: 0006153 2023-02-23 17:18 nick Note Added: 0006169 2023-02-23 17:19 nick Note Added: 0006170 2023-02-23 17:19 nick Note Deleted: 0006170 2023-02-23 17:20 nick Final Accepted Text => See https://austingroupbugs.net/view.php?id=1631#c6169 2023-02-23 17:20 nick Status New => Resolved 2023-02-23 17:20 nick Resolution Open => Accepted As Marked 2023-02-23 17:22 nick Note Edited: 0006169 2023-02-23 17:22 nick Tag Attached: issue8 2023-03-10 10:53 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001626]: Reconsider CURDIR macro
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1626 == Reported By:illiliti Assigned To: == Project:Issue 8 drafts Issue ID: 1626 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Applied Name: Mark Lundblad Organization: User Reference: Section:make Page Number:2945 Line Number:98797 Final Accepted Text:https://austingroupbugs.net/view.php?id=1626#c6130 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2023-01-04 22:25 UTC Last Modified: 2023-03-10 10:51 UTC == Summary:Reconsider CURDIR macro == Issue History Date ModifiedUsername FieldChange == 2023-01-04 22:25 illiliti New Issue 2023-01-04 22:25 illiliti Name => Mark Lundblad 2023-01-04 22:25 illiliti Section => make 2023-01-04 22:25 illiliti Page Number => 2945 2023-01-04 22:25 illiliti Line Number => 98797 2023-01-23 17:22 geoffclare Note Added: 0006130 2023-01-23 17:23 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1626#c6130 2023-01-23 17:23 geoffclare Status New => Resolved 2023-01-23 17:23 geoffclare Resolution Open => Accepted As Marked 2023-01-23 17:24 geoffclare Tag Attached: issue8 2023-03-10 10:51 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001624]: getdelim() / getline() non-success reporting clarification
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1624 == Reported By:romanzilka Assigned To: == Project:Issue 8 drafts Issue ID: 1624 Category: System Interfaces Type: Clarification Requested Severity: Comment Priority: normal Status: Applied Name: Roman Žilka Organization: User Reference: Section:getdelim() Page Number:1017-1019 Line Number:34871-34961 Final Accepted Text:https://austingroupbugs.net/view.php?id=1624#c6114 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-12-22 11:20 UTC Last Modified: 2023-03-10 10:50 UTC == Summary:getdelim() / getline() non-success reporting clarification == Issue History Date ModifiedUsername FieldChange == 2022-12-22 11:20 romanzilka New Issue 2022-12-22 11:20 romanzilka Name => Roman Žilka 2022-12-22 11:20 romanzilka Section => getdelim() 2022-12-22 11:20 romanzilka Page Number => 1017-1019 2022-12-22 11:20 romanzilka Line Number => 34871-34961 2023-01-19 17:19 geoffclare Note Added: 0006114 2023-01-19 17:20 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1624#c6114 2023-01-19 17:20 geoffclare Status New => Resolved 2023-01-19 17:20 geoffclare Resolution Open => Accepted As Marked 2023-01-19 17:21 geoffclare Tag Attached: issue8 2023-03-10 10:50 geoffclare Status Resolved => Applied ==
[1003.1(2016/18)/Issue7+TC2 0001629]: Shell vs. read(2) errors on the script
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1629 == Reported By:mirabilos Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1629 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: mirabilos Organization: mksh User Reference: Section:unsure which applies Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2023-01-15 17:30 UTC Last Modified: 2023-03-10 09:20 UTC == Summary:Shell vs. read(2) errors on the script == Relationships ID Summary -- related to 367 interaction between readonly, export, g... == -- (0006198) geoffclare (manager) - 2023-03-10 09:20 https://austingroupbugs.net/view.php?id=1629#c6198 -- > The new proposed resolution would require 'command . /some/file' to exit the shell on syntax errors, but would also require to not exit the shell on read errors. True, and this is a defect for the syntax error case, as existing shells do not exit. > The new proposed resolution requires an exit status of 126. It requires 128, not 126. The consensus in the teleconference was to agree with the comments that said 126 would not be appropriate, and also with the comments that said 128 would be a good choice. Issue History Date ModifiedUsername FieldChange == 2023-01-15 17:30 mirabilos New Issue 2023-01-15 17:30 mirabilos Name => mirabilos 2023-01-15 17:30 mirabilos Organization => mksh 2023-01-15 17:30 mirabilos URL => unsure which applies 2023-01-15 17:30 mirabilos Section => unsure which applies 2023-01-20 21:18 chet_ramey Note Added: 0006120 2023-01-30 16:45 nick Relationship added related to 367 2023-02-02 15:51 chet_ramey Note Added: 0006142 2023-02-04 17:46 chet_ramey Note Added: 0006143 2023-02-09 16:59 geoffclare Note Added: 0006145 2023-02-09 17:06 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2023-02-18 21:51 mirabilos Note Added: 0006158 2023-02-18 21:54 mirabilos Note Edited: 0006158 2023-02-20 21:14 chet_ramey Note Added: 0006160 2023-02-20 22:47 mirabilos Note Added: 0006161 2023-02-21 05:58 kreNote Added: 0006163 2023-02-22 17:25 McDutchie Note Added: 0006167 2023-02-22 17:32 McDutchie Note Edited: 0006167 2023-02-22 17:39 McDutchie Note Added: 0006168 2023-03-05 11:20 hvdNote Added: 0006192 2023-03-06 19:07 hvdNote Added: 0006195 2023-03-06 19:10 hvdNote Edited: 0006195 2023-03-06 19:11 hvdNote Edited: 0006195 2023-03-06 19:13 hvdNote Edited: 0006195 2023-03-09 17:29 geoffclare Note Added: 0006196 2023-03-09 17:44 hvdNote Added: 0006197 2023-03-10 09:20 geoffclare Note Added: 0006198 ==
