Re: How do I get the buffered bytes in a FILE *?

he "correct" solution with a stdio implementation that doesn't offer something like freadhead() is not to use stdio but implement own buffering. -- Jilles Tjoelker

Re: POSIX gettext() and uselocale()

s returned by a gettext call on a thread with uselocale() active, while logically the string may be owned by the locale and could be freed if that locale is no longer set on any thread and freelocale() has been called on it as needed. -- Jilles Tjoelker

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

idelines. One might also wonder whether the language of options and operands is still worth the trouble at this point. -- Jilles Tjoelker

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

Similarly, commands like ulimit -fH do not work in bash. It must be -Hf, -H -f or -f -H. I'm testing with GNU bash, version 5.0.18(3)-release (amd64-portbld-freebsd12.1) and version sh (AT Research) 93u+ 2012-08-01 -- Jilles Tjoelker

Re: ksh93 job control behaviour [was: Draft suggestion: Job control and subshells]

which are really different from the child's. On the other hand, it is simple to leave the parent's jobs in the data structures until the child creates the first job of its own. The only additional magic is to avoid calling waitpid() or similar until that point (to avoid strange cases with reused process IDs). -- Jilles Tjoelker

Re: ksh93 job control behaviour [was: Draft suggestion: Job control and subshells]

t is in foreground. When disabling job control in subshells, it is still possible to leave the process group by starting a new shell instance and enabling job control in that. With the benefit of hindsight, it would probably be better if a subshell implicitly turned off -m, so it can be turned on again. However, subshells implicitly modifying shell options seems rather unusual. -- Jilles Tjoelker

Re: Weird possibility with async processes, $!, and long running scripts

s still > running. Of course, a similar problem can happen here, without PID2 > being involved - with the script simply signalling some unintended process. > The only way of avoiding that would be to keep the zombies until the > script has been made aware that the process is completed, after which it > is simply a script bug if it tries to kill a process it knows is already > complete. A possible fix would be to add a magic variable that returns the most recent background job's identifier in % form, somewhat like $! in that referencing it causes the job to be remembered. Scripts would need to use the new variable instead of $!. -- Jilles Tjoelker

Re: Exporting an unset variable

D sh's maintainer, I decided that this behaviour is a bug and changed it to be in line with other shells for FreeBSD 13.0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233545 Given that this has been broken for so long, all FreeBSD 11.x and 12.x versions will not receive this fix (unless some circumstance makes it crucial to have it). -- Jilles Tjoelker

Re: EINTR on 'wait' clarification

gt; > If a blocked call to one of the following interfaces is interrupted by a > > signal handler, then the call will be automatically restarted after the > > signal handler returns if the > > SA_RESTART flag was used; otherwise the call will fail with the error > > EINTR: > > * wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2). I think there is one more compliant result of your test program: only the "wait done, pid " line, if the wait function succeeds before noticing the signal; the pending SIGCHLD signal is discarded ("accepted"). -- Jilles Tjoelker

Re: [1003.1(2008)/Issue 7 0000789]: Add set -o pipefail

f they > need shell assistance, ask for what they actually need. The pipefail option is a small bit of code in the shell to make scripts much simpler, but a similar effect can be obtained using a complicated function that only needs to be written once. > But the operation of the option needs to be fully defined (even if that > includes "is unspecified" for some things.) Yes. -- Jilles Tjoelker

Re: Should shell quoting within glob bracket patterns be effective?

he '^' a literal part of the set). I prefer "no quirk" twice as output but it is indeed not fully specified. -- Jilles Tjoelker

Re: quoting in shell parameter expressions

On Tue, Jun 20, 2017 at 04:02:10PM +0200, Joerg Schilling wrote: > Geoff Clare wrote: > > Joerg Schilling wrote, on 20 Jun 2017: > > > I would like to get a confirmation on how this expression: > > > "${xxx-"a b c"}" > > > is to be

Re: "-" operand to "sh"

On Wed, Jun 07, 2017 at 01:52:57PM +0200, Joerg Schilling wrote: > Jilles Tjoelker <jil...@stack.nl> wrote: > > In interactive mode, job control (-m) is enabled automatically. Some > > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > > starting a

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

is > Internal Field Delimiter (or Terminator, not "Separator") for > splitting (as opposed to for "$*") > That was fixed in pdksh, zsh and the Almquist shell, but > unfortunately in the mean time, POSIX specified the AT ksh way > (later, some variants of ash and pdksh have changed back to the > POSIX way). > So in POSIX shells both a''b' and a''b are split into ("a", "", > "b") so that quote() would quote both to 'a'\'''\''b' This is easily fixed by adding a quoted empty string: set -- $1'' If $1 ends with an IFS character, you get a final empty field. If $1 does not end with an IFS character, the empty string does nothing. -- Jilles Tjoelker

Re: SIGCHLD trap in a shell

y case it seems strange to tie SIGCHLD behaviour to "set -m". > * With ksh93 and zsh, I get: > 0 > 30 > 30 > 30 > 30 > 30 > [...] > (or with a 29 just after the 0 -- this is just a timing reason), > i.e. a trap execution only for asynchronous lists. > This corresponds to the behavior of ksh88 as mentioned in the > rationale for the "set" built-in. Is this the original intent? > In any case, I think that this is the most useful behavior. That seems more useful, but there is no text in POSIX that says to implement it that way. -- Jilles Tjoelker

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

ls. This appears to have the same issue as the FreeBSD sh method. I think the most important part of this bug report is that > with set -C will open a regular file exclusively. Almost all shells seem to implement this part correctly (although they did not 10 years ago). -- Jilles Tjoelker