savannah.gnu.org bug tracker unused?

[Peter Cordes]

 (I'll send another email for the bug I found, instead of having 2
topics in 1 thread).

 Does anyone look at the bug tracker on Savannah?
https://savannah.gnu.org/support/?group=bash

 I submitted a bug there, after going to the GNU project page for bash
http://www.gnu.org/software/bash/ and following the link to the
Savannah page (https://savannah.gnu.org/projects/bash/).  I now 
realize that nobody has ever closed any of the bugs there, even some
obvious candidates for CLOSE WONTFIX.

 I did notice that Chet has replied to one a couple of these bugs, but
didn't close any of them as invalid or wontfix.  So I assume the bug
tracker isn't really used.


 There have been some closed tickets on the patches page, so I guess
someone looked at that page at least at some point.
https://savannah.gnu.org/patch/?group=bash

 I was going through some bugs looking for ones I could help triage,
and found several that aren't actually bugs.  I commented on them to
explain why they weren't bugs or weren't necessary features,
summarizing here.  Hopefully this is of some use, if anyone decides to
go an look over the savannah bug page.

https://savannah.gnu.org/support/index.php?108381
 CLOSE INVALID: POSIX says arithmetic is done with signed integers, so
no, right shift is arithmetic (sign-extending) not logical, unfortunately.

https://savannah.gnu.org/support/index.php?108163
 probably invalid, pasting giant buffers into bash loses characters
because of lack of pseudo tty flow control, not bash's fault.

https://savannah.gnu.org/support/index.php?108103
 CLOSE WONTFIX: md5 checking of possibly-updated-from-dropbox stuff
can easily be done with wrapper scripts.  (This one has a comment from
someone other than the submitter, a guy that says he "really wants to
help with some code", hopefully Jonathan Ganade found his way to a
mailing list or otherwise found something to hack on.)

https://savannah.gnu.org/support/index.php?107974
 CLOSE WONTFIX, unless maybe you really really want to be able to do
 foo {$n..$m}"$tail" without needing an eval.  Or to avoid having to
bust out for (( i=n ; i<=m ; i+=k )) syntax.

https://savannah.gnu.org/support/index.php?105519
 CLOSE DONE: feature request for shopt -s autocd

https://savannah.gnu.org/support/index.php?102985
 CLOSE INVALID: contrary to the submitter's expectation, POSIX says
printf %c takes a string, not a number.  There are pure-bash
implementations of chr and ord (to use the perl names) on
http://mywiki.wooledge.org/BashFAQ/071.  (Kudos Greg Wooledge for very
excellent stuff.)  Given that, any new features to help with this are
probably not needed.  The only odd thing I found while playing around
with this is that printf %c only prints the first byte of the UTF-8
representation of a multi-byte character.  (POSIX says to be
"extremely cautious" about using %c with wide characters, apparently
for good reason.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC