Unused bash long option --debug
debug long option is not used, however it is declared. Is it for some reason? Backward compatibility? It is a bit misleading, because bash --help shows --debug as a possible option. RR
Bash long option --protected
'protected' long option has effect only when WORDEXP_OPTION is enabled, so this patch remove that option when WORDEXP_OPTION is not enabled. The following patch should clearly apply to master branch.
[PATCH] Enable protected long option only if WORDEXP_OPTION is enabled
Signed-off-by: Roman Rakus
---
shell.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/shell.c b/shell.c
index 9e74f3b..87f740a 100644
--- a/shell.c
+++ b/shell.c
@@ -248,7 +248,9 @@ static const struct {
{ "noprofile", Int, &no_profile, (char **)0x0 },
{ "norc", Int, &no_rc, (char **)0x0 },
{ "posix", Int, &posixly_correct, (char **)0x0 },
+#if defined (WORDEXP_OPTION)
{ "protected", Int, &protected_mode, (char **)0x0 },
+#endif
{ "rcfile", Charp, (int *)0x0, &bashrc_file },
#if defined (RESTRICTED_SHELL)
{ "restricted", Int, &restricted, (char **)0x0 },
--
1.7.6.5
Porting to HP NonStop: --without-bash-malloc
Hi Chet Could you add this? Prevents us from having to remember to use --without-bash-malloc diff --git a/configure.in b/configure.in index d7e0998..af72223 100644 --- a/configure.in +++ b/configure.in @@ -87,6 +87,7 @@ sparc-linux*)opt_bash_malloc=no ;;# sparc running linux; r *-beos*)opt_bash_malloc=no ;;# they say it's suitable *-cygwin*)opt_bash_malloc=no ;;# Cygnus's CYGWIN environment *-opennt*|*-interix*)opt_bash_malloc=no ;;# Interix, now owned by Microsof +*-nsk*)opt_bash_malloc=no ;;# HP NonStop esac # memory scrambling on free() Applies to at least bash-4.2.37 Bye, Jojo
Portability patch: S_IWRITE and S_IEXEC
Hi Chet Here's a portability patch, S_IWRITE and S_IEXEC are obsolete since long and got replaced by S_IWUSR and S_IXUSR respectivly diff --git a/examples/loadables/mkdir.c b/examples/loadables/mkdir.c index f41f171..f5c105e 100644 --- a/examples/loadables/mkdir.c +++ b/examples/loadables/mkdir.c @@ -109,7 +109,7 @@ mkdir_builtin (list) umask (original_umask); nmode = (S_IRWXU | S_IRWXG | S_IRWXO) & ~original_umask; - parent_mode = nmode | (S_IWRITE|S_IEXEC);/* u+wx */ + parent_mode = nmode | (S_IWUSR|S_IXUSR);/* u+wx */ /* Adjust new mode based on mode argument */ nmode &= omode; Bye, Jojo
Re: Portability patch: S_IWRITE and S_IEXEC
On 9/14/12 11:37 AM, Joachim Schmitz wrote: > parent_mode = nmode | (S_IWUSR|S_IXUSR); Thanks. This one got changed quite a while ago. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Porting to HP NonStop: --without-bash-malloc
On 9/14/12 11:35 AM, Joachim Schmitz wrote: > Hi Chet > > Could you add this? Prevents us from having to remember to use > --without-bash-malloc Thanks for the change; I'll add it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
RE: Portability patch: S_IWRITE and S_IEXEC
> From: Chet Ramey [mailto:chet.ra...@case.edu] > Sent: Friday, September 14, 2012 7:49 PM > To: Joachim Schmitz > Cc: Joachim Schmitz; Bug-bash@gnu.org; chet.ra...@case.edu > Subject: Re: Portability patch: S_IWRITE and S_IEXEC > > On 9/14/12 11:37 AM, Joachim Schmitz wrote: > > parent_mode = nmode | (S_IWUSR|S_IXUSR); > > Thanks. This one got changed quite a while ago. Well, it is still in 4.2.37. Is there something newer? I got it from git://git.sv.gnu.org/bash.git, today. Bye, Jojo
Re: Portability patch: S_IWRITE and S_IEXEC
On 9/14/12 2:07 PM, Joachim Schmitz wrote: >> From: Chet Ramey [mailto:chet.ra...@case.edu] >> Sent: Friday, September 14, 2012 7:49 PM >> To: Joachim Schmitz >> Cc: Joachim Schmitz; Bug-bash@gnu.org; chet.ra...@case.edu >> Subject: Re: Portability patch: S_IWRITE and S_IEXEC >> >> On 9/14/12 11:37 AM, Joachim Schmitz wrote: >>> parent_mode = nmode | (S_IWUSR|S_IXUSR); >> >> Thanks. This one got changed quite a while ago. > > Well, it is still in 4.2.37. Is there something newer? > I got it from git://git.sv.gnu.org/bash.git, today. I don't typically patch the examples. The newer code is in the devel branch of the git tree on savannah. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
RE: Portability patch: S_IWRITE and S_IEXEC
> From: Chet Ramey [mailto:chet.ra...@case.edu] > Sent: Friday, September 14, 2012 8:15 PM ... > I don't typically patch the examples. The newer code is in the devel > branch of the git tree on savannah. Ah, I didn't notice there were branches, thanks.
Re: square bracket vs. curly brace character ranges
Marcel Giannelia wrote:
> But the other day I was on a fresh install (hadn't set
> LC_COLLATE=C yet, so I was in en_US.UTF-8), and this happened:
>
> $ ls
> a A b B c C
> $ ls {a..c}
> a b c
The above has nothing to do with file glob expansion. Using 'ls'
there I think confuses the discussion. You can see the same result
with 'echo' and avoid the confusing use of ls like this:
$ echo {a..c}
a b c
> $ ls [a-c]
> a A b B c
The expression [a-c] is really like saying [aAbBc] in your active
locale. Using locale based character ranges outside of the C locale
is problematic and I always avoid them.
This result is due to the matching of file globs against files in the
directory. If you were to remove files for example you would see
fewer matches. (I am sure you already knew that but I wanted to say
it explicitly. Since using ls in that context adds confusion.)
> Curly brace range expressions behave differently from square-bracket
> ranges. Is this intentional?
Yes. Because bracket expansion is a file glob expansion and dependent
upon the locale. Brace expansion is a bash extension and can do what
it wants. (I am going to get in trouble for saying it that way,
because it isn't really correct, and I expect at least three
corrections. )
> The sheer number of threads we've got complaining about
> locale-dependent [a-c] suggests to me that the software should be
> changed to just do what people expect, especially since nothing is
> really lost by doing so.
I know that some projects are doing just that. I don't know the plans
for bash. I would like to see it addressed in libc so that it would
be uniform across all projects. But that isn't likely to happen. But
if libc isn't going to do it then it is beneficial if projects do it
themselves outside of libc. Eventually in the future when libc
addresses the problem then those hacks can be removed.
Bob
Re: square bracket vs. curly brace character ranges
On Fri, Sep 14, 2012 at 1:49 AM, Marcel Giannelia wrote:
> I believe I've found an inconsistency in bash or its documentation.
>
> I know the fact that things like [a-c] are highly locale-dependent in
> bash (doesn't mean I have to like it, but there it is). Fine. I've
> learned to live with it.
>
> But the other day I was on a fresh install (hadn't set
> LC_COLLATE=C yet, so I was in en_US.UTF-8), and this happened:
>
> $ touch {a..c}
> $ ls
> a b c
> $ touch {A..C}
> $ ls
> a A b B c C
> $ ls {a..c}
> a b c
> $ ls [a-c]
> a A b B c
>
> Curly brace range expressions behave differently from square-bracket
> ranges. Is this intentional? This is under Arch Linux, bash version
> "4.2.37(2)-release (i686-pc-linux-gnu)".
>
> The man page seems to imply that the curly brace behaviour above is a
> bug:
>
> "When characters are supplied, the expression expands to each character
> lexicographically between x and y, inclusive."
>
> ...although this documentation suffers from the same problem as the
> passage about character class ranges, namely that it confuses
> lexicographic sort order (character collation *weights*) with
> character collation *sequence values* (they are not quite the same thing
> -- if they were, 'c' and 'C' would *always always always* appear
> together in a range expansion, because:
> $ touch aa B cd C
> $ ls -1
> aa
> B
> C
> cd
> ). The phrases "sorts between" and "lexicographically between" refer to
> collation *weights*, but bash clearly uses sequence values.
>
> It's a subtle distinction; I beat it to death in a thread
> from 2011, subject "documentation bug re character range expressions",
> but I don't think the documentation actually got changed.
>
> It seems the thinking goes something like, "since no one is supposed to
> use expressions like [a-c], we don't have precisely
> document, care, or even *know* what it means" -- a shame, because with
> LC_COLLATE=C set, [a-c] is actually quite useful, and in all other
> locales it isn't useful at all (it would be slightly useful if it used
> weights like the documentation says because then it would be like a
> case-insensitive range, but with it using sequence values instead, it's
> useless).
>
> The sheer number of threads we've got complaining about
> locale-dependent [a-c] suggests to me that the software should be
> changed to just do what people expect, especially since nothing is
> really lost by doing so.
>
> Oh well. Dead horses and all that -- but can we at least make the dead
> horses consistent? :)
>
> ~Felix.
>
http://mywiki.wooledge.org/locale
Re: square bracket vs. curly brace character ranges
On Fri, Sep 14, 2012 at 02:48:21PM -0600, Bob Proulx wrote: > > $ ls [a-c] > > a A b B c > > The expression [a-c] is really like saying [aAbBc] in your active > locale. Using locale based character ranges outside of the C locale > is problematic and I always avoid them. It's even worse on some systems: imadev:/tmp/greg$ ls [a-c] A a Á á À à Â â Ä ä Å å Ã ã Æ æ B b C c Never use character range expressions outside of the C locale. They are implementation-defined, meaning you get totally unexpected results.
Re: square bracket vs. curly brace character ranges
On 9/14/12 4:48 PM, Bob Proulx wrote: >> The sheer number of threads we've got complaining about >> locale-dependent [a-c] suggests to me that the software should be >> changed to just do what people expect, especially since nothing is >> really lost by doing so. > > I know that some projects are doing just that. I don't know the plans > for bash. I would like to see it addressed in libc so that it would > be uniform across all projects. But that isn't likely to happen. But > if libc isn't going to do it then it is beneficial if projects do it > themselves outside of libc. Eventually in the future when libc > addresses the problem then those hacks can be removed. http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
