Re: feature request: allow shif [n] with n > $#
On Sat, Apr 13, 2019 at 09:43:47AM +0200, Toralf Förster wrote:
> Except, that I used the opposite:
>
> min_days=${1:-5}
> min_hours=${2:-12}
> min_compl=${3:-3500}
> shift "$(( $# < 3 ? $# : 3 ))"
> setupargs="$@"
So... this user interface of yours. It looks something like
myprog [days] [hours] [compl] [file ...]
So if the user passes two numeric arguments and then a filename, the
third filename becomes "compl" (whatever that is, but it seems to be
numeric)?
If the user passes two numeric arguments and then 17 filenames, the
first filename becomes "compl" and gets shifted away, and then only
the last 16 filenames are processed?
I'm seeing a whole lot of pitfall here and not much safety net.
Re: feature request: allow shif [n] with n > $#
On Mon, Apr 15, 2019 at 08:42:53AM -0400, Greg Wooledge wrote:
> On Sat, Apr 13, 2019 at 09:43:47AM +0200, Toralf Förster wrote:
> > Except, that I used the opposite:
> >
> > min_days=${1:-5}
> > min_hours=${2:-12}
> > min_compl=${3:-3500}
> > shift "$(( $# < 3 ? $# : 3 ))"
> > setupargs="$@"
>
> So... this user interface of yours. It looks something like
>
> myprog [days] [hours] [compl] [file ...]
>
> So if the user passes two numeric arguments and then a filename, the
> third filename becomes "compl" (whatever that is, but it seems to be
> numeric)?
>
> If the user passes two numeric arguments and then 17 filenames, the
> first filename becomes "compl" and gets shifted away, and then only
> the last 16 filenames are processed?
>
> I'm seeing a whole lot of pitfall here and not much safety net.
Also, you are squashing all of your filename arguments down into a
single string variable, presumably to be word-split later. Which
will blow up when one of those arguments contains whitespace or glob
characters.
If you want to store a list of arguments, use an array variable instead
of a string variable.
Re: feature request: allow shif [n] with n > $#
Date:Mon, 15 Apr 2019 09:19:19 -0400 From:Greg Wooledge Message-ID: <20190415131919.gy6...@eeg.ccf.org> | > > setupargs="$@" | Also, you are squashing all of your filename arguments down into a | single string variable, This is simply an unspecified operation - often interpreted the same as setupargs="$*" but that's not guaranteed. It could do anything... (obviously when you know it is bash processing the script, there will be one particular thing.) kre
Re: process substitution and wait()
On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote: > It's an easy change. See the attachment. Thanks! The attached patch removed a comment and changed an #if 1 to #if 0, but i think the comment change is just a cleanup reflecting the previous state of the codebase. Is that right? > I agree that the negative side effects outweigh the requests to have the > shell `fully clean up after itself'. I see this change has already been applied to the devel branch. Thanks! Will it also be applied to the master branch (against 5.0)? Regards, --dkg signature.asc Description: PGP signature
Re: issues in bash found while creating command result display
On 4/14/19 9:40 PM, Paul Wise wrote:
> On Sun, 2019-04-14 at 17:28 -0400, Chet Ramey wrote:
>
>> That's the number of positional parameters.
>
> Oops, I mean the command number variable \# that is available at PS1
> evaluation time but not when PROMPT_COMMAND is run. I was able to
> workaround this by deferring the decision to display the status until
> the PS1 evaluation time and using math functions to access and store
> the command number variable \# to a normal variable.
You can use $HISTCMD with a slight fix that's now in the devel branch.
>
>> Syntax errors set $? to 2. SIGINT at the prompt sets $? to 130. There's
>> no way to determine whether or not those exit statuses differ from an
>> exit status resulting from a command being run.
>
> I managed to workaround this with some heuristics but it would be much
> nicer to be able to properly differentiate between these cases.
The Korn shell uses values > 256 to denote `internal' shell exit statuses,
but that violates POSIX.
>
>> PIPESTATUS doesn't get set until a job completes. $? will be reset to
>> 128+SIGNUM when a job stops, since that is what shells do and it seems
>> reasonable as a way to let the user know a job suspended. It doesn't seem
>> particularly useful to set PIPESTATUS to, e.g., {146, 146, 146} in this
>> case, though.
>
> Having the former value of PIPESTATUS when $? has been reset doesn't
> seem useful either, I think it would be better to unset PIPESTATUS when
> setting $? but not PIPESTATUS if you aren't going to set PIPESTATUS.
I'll keep that in mind for a future version.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: process substitution and wait()
On 4/15/19 2:40 PM, Daniel Kahn Gillmor wrote: > On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote: >> It's an easy change. See the attachment. > > Thanks! The attached patch removed a comment and changed an #if 1 to > #if 0, but i think the comment change is just a cleanup reflecting the > previous state of the codebase. Is that right? Yes. > >> I agree that the negative side effects outweigh the requests to have the >> shell `fully clean up after itself'. > > I see this change has already been applied to the devel branch. Thanks! > Will it also be applied to the master branch (against 5.0)? I'll probably release a patch, yes. In the meantime, distributions are free to take the change and apply it to their versions. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: process substitution and wait()
On Mon 2019-04-15 17:35:49 -0400, Chet Ramey wrote: > I'll probably release a patch, yes. In the meantime, distributions are free > to take the change and apply it to their versions. Thanks for the followup! I've updated https://bugs.debian.org/920455 with the appropriate details. --dkg
Re: issues in bash found while creating command result display
On Mon, 2019-04-15 at 17:31 -0400, Chet Ramey wrote: > You can use $HISTCMD with a slight fix that's now in the devel branch. That doesn't increment when you use HISTCONTROL=erasedups AFAICT but the command number does increment. Also HISTCMD doesn't start at zero. > The Korn shell uses values > 256 to denote `internal' shell exit statuses, > but that violates POSIX. I wonder if bash could set an additional variable to indicate if $? is from a normal exit, a signal exit, a shell keystroke etc, as well as a corresponding equivalent array that is about PIPESTATUS. > I'll keep that in mind for a future version. Thanks for that. -- bye, pabs https://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Re: issues in bash found while creating command result display
Date:Tue, 16 Apr 2019 10:29:36 +0800 From:Paul Wise Message-ID: <5be7a3060ecb029ac36a4592bbee7fc071becd12.ca...@bonedaddy.net> | I wonder if bash could set an additional variable to indicate if $? is | from a normal exit, a signal exit, a shell keystroke etc, That's really hard to do and do correctly. Eg: in (crashes && burns) assuming crashes exits with a signal, inside the subshell your new variable could be created, but where you care about the exit status is in the parent code, outside the sub-shell, and that subshell does not exit with a signal, rather it exits with the status of the last command that was run. That's 139 (or whatever). There's no way to pass variables back from a subshell, so what do you do now? Facilities that kind of work, sometimes, are worse that those that don't exist at all. kre ps: in that example, the "&& burns" is just there to prevent this from being a case where the shell running the subshell could simply do "exec crashes" in which case the parent would get the exit status directly from crashes, and could work out that it exited because of a signal. But with that extra conditional it cannot be done that way, the subshell needs to run crashes, wait for it to finish (exit because of a signal we are assuming) - which causes false as its status, so burns is not run (not attempted) and the shell exits with the exit status from crashes.
Re: issues in bash found while creating command result display
On Tue, 2019-04-16 at 12:38 +0700, Robert Elz wrote: > That's really hard to do and do correctly. I was operating on the assumption that it could be done in the same way that the $? and $PIPESTATUS variables are created/updated. > There's no way to pass variables back from a subshell I think I would just ignore subshells since $PIPESTATUS is also not passed back from subshells. So the variable I propose would be related to the exit code of the subshell rather than anything it ran. If one did want to add a way to pass back variables, since bash uses itself for subshells (AFAICT), this feature could be added by using creating a shared memory segment or a pipe or something and adding a BASH_SUBSHELL_VARS environment variable that the subshell could use to determine where to write the variables back to. -- bye, pabs https://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
