Bash patches format

[Marty E. Plummer]

Greetings,

In doing some research into ways to better improve the gentoo ebuild qa,
I ran across the fact that the official bash patches are provided as
-p0, context diffs.

I was hoping I could convince you to convert to -p1, unified diffs, such
as are produced by diff -u or git format-patch, for the following
reasons.

1.  unified diffs are easier to size up at a glance as compared
to an equivalent context diff; the two following snippets cover the same
data/changes, but the unified diff is easier to read at a glance:

*** a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
--- b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
***
*** 308,312 
{
  if (history_stifled && history_max_entries > 0)
!   history_size = history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;
--- 310,316 
{
  if (history_stifled && history_max_entries > 0)
!   history_size = (history_max_entries > MAX_HISTORY_INITIAL_SIZE)
!   ? MAX_HISTORY_INITIAL_SIZE
!   : history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;

--- a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
+++ b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
@@ -308,5 +310,7 @@
{
  if (history_stifled && history_max_entries > 0)
-   history_size = history_max_entries + 2;
+   history_size = (history_max_entries > MAX_HISTORY_INITIAL_SIZE)
+   ? MAX_HISTORY_INITIAL_SIZE
+   : history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;

2. unified diffs are, generally speaking, smaller than an equivalent
context diff, as in hunks where lines are added and removed or changed
(instead of just adding or removing lines), the hunk is copied twice in
a context diff. Depending on the general composition of a patch, an
equivalent unified diff is about 1/3 smaller than the same context diff.

3. A lot of downstream consumers are already taking these patches and
converting them to -p1 unified diffs in their source repos already, or,
barring that, have to make explicit exceptions to the 'norm' for their
packaging/buildscripts. For instance, fedora[1] and debian[2] 'mirror'
the official patchset, after converting them to -p1 unified, and gentoo
has to make an exception[3] to their eapply call in src_prepare() to
apply -p0 patches.

The above being said, I don't believe in asking for something to be done
without making an attempt of it yourself if it is within your ability.
As such, I have taken it upon myself to do the conversion for bash44-{001..019},
and am more than willing to do the same for any other existing patches,
if you're willing to continue to provide official patches in this
format, for the sake of reduction of duplicated work across all distros.
You can find them in my bash-patches[4] github repository.

Regards,
Marty.

[1]: https://src.fedoraproject.org/rpms/bash/tree/master
[2]: https://sources.debian.org/patches/bash/
[3]: 
https://github.com/gentoo/gentoo/blob/master/app-shells/bash/bash-4.4_p19.ebuild#L85-L87
Note the second patch, which is -p1, does not require extra args to
eapply
[4]: https://github.com/hanetzer/bash-patches

Documentation for a="$@"

[Ilkka Virta]

In Bash, using "$@" in an assignment, (as in  a="$@" ) concatenates the 
positional parameters to single string, joined with spaces. Somewhat 
similarly to what "$*" does, except that $* uses the first letter of 
IFS, but $@ always uses a space.


However, I can't see this documented in the manual, is it somewhere?


"3.4 Shell Parameters" [1] discusses assignments to variables, and 
there's the phrase: "Word splitting is not performed, with the exception 
of "$@" as explained below." But the actual explanation seems to be 
missing, as there's no other mention of $@ on the page.


There's also no mention of assignments under "3.4.2 Special Parameters" 
[2]. It simply states that "$@" expands to separate words.



I'd suggest adding something like this to the description of $@ in 3.4.2:

""
If $@ or "$@" is used on the right hand side of an assignment to a 
variable, it instead expands to a single word with the value of each 
positional parameter separated by a space. That is, a="$@" is equivalent 
to a="$1 $2 ...".

""



(It seems the online manual is an older version than that in git, but I 
didn't see this mentioned in the devel version of the manual either.)



[1] https://www.gnu.org/software/bash/manual/html_node/Shell-Parameters.html
[2] 
https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html



--
Ilkka Virta / itvi...@iki.fi

Re: Documentation error

[Chet Ramey]

On 5/18/18 5:09 PM, Jorge Maldonado Ventura wrote:
>> After the string is decoded, it is expanded via parameter expansion,
> command substitution, arithmetic expansion, and quote removal, subject
> to the value of the |promptvars| shell option (see _Bash Builtins_).
> 
> The documentation should point to the *The Set Builtin*, which is the
> section that covers the shell options, not Bash Builtins.

Thanks for the report. You're on the right track, but promptvars is not
an option to set. The reference should be to the shopt builtin, which
does have its own section.

-- 
``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: Documentation for a="$@"

[Chet Ramey]

On 5/19/18 3:40 PM, Ilkka Virta wrote:
> In Bash, using "$@" in an assignment, (as in  a="$@" ) concatenates the
> positional parameters to single string, joined with spaces. Somewhat
> similarly to what "$*" does, except that $* uses the first letter of IFS,
> but $@ always uses a space.

The key is word splitting, not assignment in particular.  The shell uses
spaces to separate the positional parameters if the word is not going to
be split. I will add somethng to describe that.

-- 
``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/