Re: Bash patches format

2018-05-30 Thread Todd Zullinger
Marty E. Plummer wrote: > On Wed, May 30, 2018 at 09:15:04AM -0400, Chet Ramey wrote: >> On 5/29/18 8:25 PM, Marty E. Plummer wrote: >> If people are willing to do the conversion between patch formats for their own purposes, more power to them. I don't see any compelling reason to c

Re: Bash patches format

2018-05-30 Thread Todd Zullinger
Chet Ramey wrote: > On 5/29/18 11:44 PM, Todd Zullinger wrote: > >> The main difference is the lack of detail in the git commit >> message. It would great if the same data found in the >> bash44-019 patch file was added to the git commit message. > > This is certainly doable. I would just have t

Re: Bash patches format

2018-05-30 Thread Marty E. Plummer
On Wed, May 30, 2018 at 04:59:15PM +0200, Christian Weisgerber wrote: > Marty E. Plummer: > > > Maintainers, I'd really like to hear your thoughts on this matter. If > > the diffs are produced as -p1 unified diffs, then downstreams who do > > convert from -p0 context won't have to, and distros who

Re: Bash patches format

2018-05-30 Thread Marty E. Plummer
On Wed, May 30, 2018 at 09:15:04AM -0400, Chet Ramey wrote: > On 5/29/18 8:25 PM, Marty E. Plummer wrote: > > >> If people are willing to do the conversion between patch formats for their > >> own purposes, more power to them. I don't see any compelling reason to > >> change the format I use. > >>

Re: Conditions with logical operators and nested groups execute "if" and "else"

2018-05-30 Thread L A Walsh
uriel: You didn't say what you expected the behavior to be in your bottom conditional, but remember, you start with -e-e-e--debug; you lop off the 1st -e (did you mean to use ## instead of #?) so last statement of 1st indent was ! "-e-e--debug =~ ^- so the regex matches (true) and then you say '

Re: Conditions with logical operators and nested groups execute "if" and "else"

2018-05-30 Thread L A Walsh
Ilkka Virta wrote: On 22.5. 00:17, Uriel wrote: As you know, a conditional is of the type: if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi Or with logical operators and groups: [[ EXPRESSION ]] && { TRUE CONDITION; } || { ALTERNATIVE RESULT; } No, those are no

Re: why is dash confused with underscore in autocompletion?

2018-05-30 Thread L A Walsh
Chet Ramey wrote: Linda: it's a readline option. It's off by default. You turned it on somewhere in your environment. If you don't like the behavior, find out where you enabled it and turn it off again. --- I find the man page wrong or misleading w/r/t the map-case option: If set to

Re: Bash patches format

2018-05-30 Thread Christian Weisgerber
Marty E. Plummer: > Maintainers, I'd really like to hear your thoughts on this matter. If > the diffs are produced as -p1 unified diffs, then downstreams who do > convert from -p0 context won't have to, and distros who work around it > won't either. Speaking in my capacity as the OpenBSD packager

Re: Bash patches format

2018-05-30 Thread Chet Ramey
On 5/29/18 11:44 PM, Todd Zullinger wrote: > The main difference is the lack of detail in the git commit > message. It would great if the same data found in the > bash44-019 patch file was added to the git commit message. This is certainly doable. I would just have to change the script I use. -

Re: Bash patches format

2018-05-30 Thread Chet Ramey
On 5/29/18 8:25 PM, Marty E. Plummer wrote: >> If people are willing to do the conversion between patch formats for their >> own purposes, more power to them. I don't see any compelling reason to >> change the format I use. >> > Could I at least convince you to start doing -p1, if not unified? Wh

Re: why is dash confused with underscore in autocompletion?

2018-05-30 Thread Chet Ramey
On 5/29/18 7:15 PM, L A Walsh wrote: >    I often ignore case for filenames, as I often interact > with windows, but windows does not treat '-' and '_' as the > same character.  Having bash be the one exception that considers > them to be case-variations isn't logical nor helpful as having > a rul

Re: Bash patches format

2018-05-30 Thread Marty E. Plummer
On Wed, May 30, 2018 at 10:30:10AM +0200, Emanuel Haupt wrote: > "Marty E. Plummer" wrote: > > On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote: > > > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer > > > wrote: > > > > > > > > If people are willing to do the conversion between patch

Re: Bash patches format

2018-05-30 Thread Vladimir Marek
> > > > If people are willing to do the conversion between patch formats for > > > their > > > > own purposes, more power to them. I don't see any compelling reason to > > > > change the format I use. > > > > > > > Could I at least convince you to start doing -p1, if not unified? > > > > > > > I t

Re: Bash patches format

2018-05-30 Thread Emanuel Haupt
"Marty E. Plummer" wrote: > On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote: > > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer > > wrote: > > > > > > If people are willing to do the conversion between patch > > > > formats for > > > their > > > > own purposes, more power to them.

Re: Bash patches format

2018-05-30 Thread Todd Zullinger
Hi, Marty E. Plummer wrote: >> If people are willing to do the conversion between patch formats for their >> own purposes, more power to them. I don't see any compelling reason to >> change the format I use. >> > Could I at least convince you to start doing -p1, if not unified? Don't we essentia

Re: Bash patches format

2018-05-30 Thread Marty E. Plummer
On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote: > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer > wrote: > > > > If people are willing to do the conversion between patch formats for > > their > > > own purposes, more power to them. I don't see any compelling reason to > > > change