shell.c:41:17: fatal error: pwd.h: No such file or directory
Hello, I get a compilation error during a build of bash 4.3.30 on MSYS, MinGW. Enclosed are logs of ./configure and make commands. Could you fix it or advise a solution/workaround? Rind Regards, Raveh Neeman Freelancer Codeh Technologies, Yokneam, Israel mob: +972-544-634-318 log.configure Description: log.configure log.make Description: log.make
inconsistent synopses in help output
In the output of the 'help' command in any bash upto and including 4.4-beta, the possible arguments in most of the commands listed are shown in lowercase, but for some they are in uppercase. Examples: alias [-p] [name[=value] ... ] break [n] case WORD in [PATTERN [| PATTERN]...) COMMANDS ;;]... esac dirs [-clpv] [+N] [-N] enable [-a] [-dnps] [-f filename] [name ...] for NAME [in WORDS ... ] ; do COMMANDS; done help [-dms] [pattern ...] local [option] name[=value] ... while COMMANDS; do COMMANDS; done This is inconsistent. What's more, in the descriptions that follow when you do 'help SOMECOMMAND', the arguments are always referred to in uppercase. For example in the output of 'help break' it says: "If N is specified, break N enclosing loops." But its synopsis line says: "break: break [n]". It would be much clearer if the synopsis and the description would both use uppercase for this argument, just like the 'dirs' command already does. Also, using uppercase for arguments makes it much easier to see what is a word that needs to be replaced and what is a keyword that must be typed as is, like in the 'case' and 'for' commands. For example: command [-pVv] command [arg ...] would be clearer when written as: command [-pVv] COMMAND [ARG ...] So... I propose to write all replaceable argument words in the help sysnopses in uppercase, just like they are in the reference manual (the Info document). I can make the patch, if you wish. Benno -- http://www.fastmail.com - IMAP accessible web-mail
Bash crash
Dear, We have two products which are using bash 4.2 and 4.3 separately. They all meet bash crash issue. Please refer to the attached files. It is hard for me to understand the bash source code to find the root cause out. Please let me know if you have or need more information. Thank you very much. dead.bashbug4.2 Description: dead.bashbug4.2 dead.bashbug4.3 Description: dead.bashbug4.3
[PATCH] Correct typo in builtins man page
--- doc/builtins.0 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/builtins.0 b/doc/builtins.0 index dcdc6c5..26b3580 100644 --- a/doc/builtins.0 +++ b/doc/builtins.0 @@ -1592,7 +1592,7 @@ BBAASSHH BBUUIILLTTIINN CCOOMMMMAANNDDSS function or a script executed with the .. or ssoouurrccee builtins fin- ishes executing. - If a _s_i_g_s_p_e_c is EERRRR, the command _a_r_g is executed whenever a a + If a _s_i_g_s_p_e_c is EERRRR, the command _a_r_g is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status, subject to the following conditions. The EERRRR trap is not executed if the -- 2.4.3
Re: Bash crash
On 10/19/15 10:47 PM, Kai Wang X wrote: > Dear, > > > > We have two products which are using bash 4.2 and 4.3 separately. They all > meet bash crash issue. Please refer to the attached files. > > It is hard for me to understand the bash source code to find the root cause > out. It really looks like sbrk(2) is failing here, but since I don't have any way to reproduce it, that may not be it. This could be caused by your process exceeding its memory resource limit or your system's swap space being exhausted. 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: [PATCH] Correct typo in builtins man page
On 10/20/15 6:00 AM, Vascom wrote: > --- > doc/builtins.0 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/builtins.0 b/doc/builtins.0 > index dcdc6c5..26b3580 100644 > --- a/doc/builtins.0 > +++ b/doc/builtins.0 > @@ -1592,7 +1592,7 @@ BBAASSHH BBUUIILLTTIINN > CCOOMMMMAANNDDSS >function or a script executed with the .. or > ssoouurrccee builtins fin- >ishes executing. > > - If a _s_i_g_s_p_e_c is EERRRR, the command _a_r_g > is executed whenever a a > + If a _s_i_g_s_p_e_c is EERRRR, the command _a_r_g > is executed whenever a >pipeline (which may consist of a single simple command), a > list, >or a compound command returns a non-zero exit status, subject > to >the following conditions. The EERRRR trap is not > executed if the Thanks for the report; good catch. 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: [PATCH] Correct typo in builtins man page
Vascom writes: > doc/builtins.0 | 2 +- This is a generated file. You need to edit doc/bash.1. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
On 10/20/15 2:31 AM, Raveh Neeman wrote: > Hello, > > > I get a compilation error during a build of bash 4.3.30 on MSYS, MinGW. Try the attached patch. 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/ *** ../bash-4.3-patched/shell.c 2014-12-29 14:39:43.0 -0500 --- shell.c 2015-10-20 09:35:37.0 -0400 *** *** 39,43 #include #include "filecntl.h" ! #include #if defined (HAVE_UNISTD_H) --- 39,45 #include #include "filecntl.h" ! #if defined (HAVE_PWD_H) ! # include ! #endif #if defined (HAVE_UNISTD_H)
The character can also be an "IFS whitespace character"
Quoting from the bash manual: "If IFS has a value other than the default, then sequences of the whitespace characters *space and tab* are ignored at the beginning and end of the word, as long as the whitespace character is in the value of IFS (an IFS whitespace character)." If this is true, then the following script $ IFS=$'\n' $ a=$'\n1\n2\n' $ printf "%s\n" $a 1 2 should print <> <1> <2> 3 fields, but it doesn't. So I guess *space and tab* should be replace by *space, tab and newline* in that section.
Re: The character can also be an "IFS whitespace character"
On 10/20/15 10:21 AM, ziyunfei wrote: > Quoting from the bash manual: > > "If IFS has a value other than the default, then sequences of the whitespace > characters *space and tab* are ignored at the beginning and end of the word, > as long as the whitespace character is in the value of IFS (an IFS whitespace > character)." > > If this is true, then the following script > > $ IFS=$'\n' > $ a=$'\n1\n2\n' > $ printf "%s\n" $a > 1 > 2 > > should print <> <1> <2> 3 fields, but it doesn't. > > So I guess *space and tab* should be replace by *space, tab and newline* in > that section. That seems reasonable. -- ``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/
HISTFILE=/dev/null, HISTSIZE=0 removes /dev/null on exit
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: setting HISTFILE=/dev/null and HISTSIZE=0 will replace /dev/null with regular file on exit (when running as root). Repeat-By: start bash with root priviledges HISTFILE=/dev/null HISTSIZE=0 exit Fix: Check if HISTFILE points to regular file before unlink/recreate?
Re: HISTFILE=/dev/null, HISTSIZE=0 removes /dev/null on exit
On 10/20/15 11:03 AM, Marko Teiste wrote: > Description: > setting HISTFILE=/dev/null and HISTSIZE=0 will replace /dev/null > with regular file on exit (when running as root). > > Repeat-By: > start bash with root priviledges > HISTFILE=/dev/null > HISTSIZE=0 > exit > > Fix: > Check if HISTFILE points to regular file before unlink/recreate? Thanks for the report. This has been fixed for the next release of bash. -- ``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: updating shopt compat settings to include current version
On 16 Oct 2015 11:37, Chet Ramey wrote: > On 10/15/15 5:30 PM, Mike Frysinger wrote: > >>> the bash compat feature seems to address this nicely: our standard says > >>> we should use bash-3.2, so we set the compat level to that, and then we > >>> have much stronger confidence in newer versions not breaking, or people > >>> adding code that only works on newer versions. > >> > >> You should approach this with caution. I'm sure there are changes and bug > >> fixes that introduce incompatible behavior that are not addressed by the > >> compatNN variables. I guess as long as it doesn't bite you, you're ok. > > > > right. we're OK with reporting & getting those fixed. > > Sometimes they're not going to be `fixed'. Many times those are really > bug fixes or fixes for greater consistency or compatibility. we're not looking for perfect. we understand there's no way to guarantee that (short of keeping around an old version of bash and never upgrading it). the point is to improve the status quo. > >> I mean, in theory, it's simple to do that: > >> > >> unset BASH_COMPAT > >> shopt -u compat31 > >> command shopt -s compat32 2>/dev/null > > > > ... but that doesn't work in bash-3.2: > > $ bash-3.2 -c 'shopt -s compat32' > > bash-3.2: line 0: shopt: compat32: invalid shell option name > > No, it really does. That's why I redirected the output to /dev/null. If > you run with `set -e' enabled, you can follow it with `|| :'. > > Running those commands leaves shell_compatibility_level == 32 on all > existing versions of bash >= bash-3.2. The trick is that on bash-3.2, > unsetting compat31 sets the shell compatibility level to 32, so the > failed attempt to set compat32 doesn't make a difference. my point was to have a code snippet that works for any bash version and a shifting base. we've established that you aren't interested in adding more compat flags, and that BASH_COMPAT is not useful for error checking. fine, we'll just add some ad-hoc checks ourselves using the existing bash version variables. that isn't supposed to sound petulant, just accepting of the reality of the situation. -mike signature.asc Description: Digital signature
Re: HISTFILE=/dev/null, HISTSIZE=0 removes /dev/null on exit
hey,
just out of curiosity, does this fix it (sorry I just finished when
you wrote that it had been fixed):
diff --git a/bashhist.c b/bashhist.c
index d4c62e7..9b5cf5d 100644
--- a/bashhist.c
+++ b/bashhist.c
@@ -354,7 +354,7 @@ save_history ()
int r;
hf = get_string_value ("HISTFILE");
- if (hf && *hf && file_exists (hf))
+ if (hf && *hf && file_exists (hf) && file_isregular(hf))
{
/* Append only the lines that occurred this session to
the history file. */
diff --git a/general.c b/general.c
index 087689e..1b5d6cf 100644
--- a/general.c
+++ b/general.c
@@ -549,6 +549,15 @@ file_exists (fn)
}
int
+file_isregular (fn)
+ char *fn;
+{
+ struct stat sb;
+
+ return ((stat (fn, &sb) == 0) && S_ISREG (sb.st_mode));
+}
+
+int
file_isdir (fn)
char *fn;
{
cheers,
pg
On Tue, Oct 20, 2015 at 8:42 PM, Chet Ramey wrote:
> On 10/20/15 11:03 AM, Marko Teiste wrote:
>
>> Description:
>> setting HISTFILE=/dev/null and HISTSIZE=0 will replace /dev/null
>> with regular file on exit (when running as root).
>>
>> Repeat-By:
>> start bash with root priviledges
>> HISTFILE=/dev/null
>> HISTSIZE=0
>> exit
>>
>> Fix:
>> Check if HISTFILE points to regular file before unlink/recreate?
>
> Thanks for the report. This has been fixed for the next release of bash.
>
> --
> ``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: HISTFILE=/dev/null, HISTSIZE=0 removes /dev/null on exit
On 10/20/15 2:53 PM, Piotr Grzybowski wrote: > hey, > > just out of curiosity, does this fix it (sorry I just finished when > you wrote that it had been fixed): Well, it does, but it's overkill on one hand and doesn't fix the underlying problem on the other. What you want to avoid is truncating the history file (HISTSIZE=0) or writing to a temp file and renaming it over a non-regular file (/dev/null). Those changes are made in the history library. 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: Bash crash
Hi Chet, Thank you for your response. But it does not make sense since sbrk failure will be checked: mp = (union mhead *) sbrk (sbrk_amt); /* Totally out of memory. */ if ((long)mp == -1) goto morecore_done; The script just runs when my equipment boots up. Also it is hard to reproduce in my environment. Only every few times of my equipment booting up, it generates a coredump file. -Original Message- From: Chet Ramey [mailto:chet.ra...@case.edu] Sent: 2015年10月20日 21:31 To: Kai Wang X; bug-bash@gnu.org Cc: chet.ra...@case.edu Subject: Re: Bash crash On 10/19/15 10:47 PM, Kai Wang X wrote: > Dear, > > > > We have two products which are using bash 4.2 and 4.3 separately. They > all meet bash crash issue. Please refer to the attached files. > > It is hard for me to understand the bash source code to find the root > cause out. It really looks like sbrk(2) is failing here, but since I don't have any way to reproduce it, that may not be it. This could be caused by your process exceeding its memory resource limit or your system's swap space being exhausted. 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: why must bash zap last search string just because we hit ^C?
> Press Ctrl-u OK I see this also works for $ ^Rabcdefg^U $ some command the boss told me to do $ ^R^R and voila! I am back to searching "abcdefg" again. OK, I'll remember ^U. Case closed. Thanks everybody.
