Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
Dear Chet, Thank you for your attention and fast reply. I added your patch and now observe further errors in the code of shell.c Enclosed is a compilation log. Raveh From: Chet Ramey Sent: Tuesday, October 20, 2015 4:39 PM To: Raveh Neeman; bug-bash@gnu.org Cc: chet.ra...@case.edu Subject: 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/ log.make Description: log.make
Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
> Thank you for your attention and fast reply. > I added your patch and now observe further errors in the code of shell.c > Enclosed is a compilation log. Thanks, I'll look at these. Note that you can get bash already built for MinGW. -- ``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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/15 2:49 PM, Mike Frysinger wrote: 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. I f >> 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 mo re > compat flags, and that BASH_COMPAT is not useful for error checking. fin e, > we'll just add some ad-hoc checks ourselves using the existing bash versi on > variables. that isn't supposed to sound petulant, just accepting of the > reality of the situation. I don't think you're petulant. I gave you the code snippet you wanted. You can use whatever you'd like. - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEUEARECAAYFAlYnkUcACgkQu1hp8GTqdKvFyACXSeoqrLQ/vBFWEWRvTnMCNIcA IwCfT7JtZUOxc+y/PWCSa5rUMJzubg0= =W03D -END PGP SIGNATURE-
Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
Yes Chet, I'll probably get a precompiled binary... Thanks for your efforts. Raveh From: Chet Ramey on behalf of Chet Ramey Sent: Wednesday, October 21, 2015 3:56 PM To: Raveh Neeman Cc: bug-bash@gnu.org; chet.ra...@case.edu; c...@po.cwru.edu Subject: Re: shell.c:41:17: fatal error: pwd.h: No such file or directory > Thank you for your attention and fast reply. > I added your patch and now observe further errors in the code of shell.c > Enclosed is a compilation log. Thanks, I'll look at these. Note that you can get bash already built for MinGW. -- ``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
On 10/20/15 10:29 PM, Kai Wang X wrote: > 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; Sure, sbrk failure is checked, but not whether it returns an invalid value. The segmentation fault occurs when the bash malloc attempts to dereference the value returned by sbrk. If the memory access generates a fault, it's either 0 or out of bounds. Either way, sbrk returned a bad value without raising an error. 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
Sounds like a hardware problem with the RAM on your system HTH, Arnold In article you write: >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/ -- Aharon (Arnold) Robbins arnold AT skeeve DOT com
Re: language inconsistency(wart) & RFE
Greg Wooledge wrote:
--- please note locations of 'auto_local'
# at beginning
shopt -s auto_local
# Pick unbiased random number from 0 to N-1 ($1 = N)
# Returns value in variable r.
rand() {
shopt -u auto_local
local max=$((32768 / $1 * $1))
while (( (r=$RANDOM) >= max )); do :; done
r=$(( r % $1 ))
shopt -s auto_local
}
foo() {
local r
rand 6
echo "I rolled $((r+1))"
}
foo
# r is not visible here
Under your proposal, the variable r which
is defined locally in foo, and
is up-scope-visible to rand (so that rand can put a return value into
it), would also be defined locally within r,
so there would be no way to
return a value from rand to foo.
Under my proposal, it is a shopt option that can be turned
on or off. When it is off, things behave as they do no. When it is
on, vars w/o a specific declarator, or declarator+"-g switch" would
be default to be local.
(If you want to attack "language warts", start with the inability to
return values from functions to their callers!)
---
They can -- unfortunately, it is by printing to, usually,
to stdout, and reading it in the parent (I agree this is a rather
roundabout and inefficient way to send return vals...
I've thought about that, but running into inconsistencies in the
dynamic variable propagation. It's hard to define an
"alternate syntax" when the primary syntax doesn't consistently
yield the same answer. So need to figure that out first.
Hopefully the toggling of 'auto_local' isn't hard to understand:
it's like adding a -i or -l flag to var declaration -- doesn't
affect current values in vars, but only new assignments.
Re: language inconsistency(wart) & RFE
Here is an example of what I consider to be
strange and/or inconsistent behavior ( tests
2 & 3 fail).
test 3's failure is a real puzzler:
-
#!/bin/bash
shopt -s expand_aliases ; alias my=declare
alias array='my -a' int='my -i'
dmp () { printf "%q\n" "${*:?}" ; }
ip=10.20.30.40
array parts=()
(IFS=.; parts=( $ip ) )
array answers=(
'10 20 30 40'
'1 .2 .3 .4'
'1 222 .3 .4'
'192.168.0.1/24::{ [ipaddr]="192.168.0.1/24" [address]="192.168.0.1" [prefixlen]="24" ; }'
)
#
array addr_fields=(ipaddr address prefixlen)
assignparts() { parts=( $ip ) ; }
tst0 () { my IFS=. ; assignparts ; echo -E "${parts[@]}"; }
tst1 () { my IFS=0 ; assignparts ; echo -E "${parts[@]}"; }
tst2 () { parts[1]=222; echo -E "${parts[@]}" ; }
tst3 () {
my ipaddr="$1"; shift;
int status=0
my pat='^([^/]+)/([0-9]+)\s*$'
my address prefixlen
if [[ ! $ipaddr =~ $pat ]]; then
echo >&2 "Error in ip/netsize format: \"$ipaddr\""
status=1
else
address=${BASH_REMATCH[1]}
prefixlen=${BASH_REMATCH[2]}
my out=""
for flds in "${addr_fields[@]}"; do
out+="[$flds]=\"${!flds}\" "
done
printf "{ %s; }" "$out"
fi
return $status
}
int passno=0 tests=0
my fmt="Case %d got/Expected:\n \"%q\"\n \"%q\"\n"
testor () {
int tstno
my out=""
for tstno in {0..3}; do
tests+=1
exp="${answers[tstno]}"
if [[ $exp =~ :: ]]; then
my args="${exp%::*}"
exp="${exp#*::}"
out="$(tst$tstno $args)"
else
out="$(tst$tstno)"
fi
if [[ $out != $exp ]]; then
printf >&2 "$fmt" "$tstno" "$out" "$exp"
continue
fi
passno+=1
done
}
testor
echo "Passed $passno/$tests tests."
output:
Case 2 got/Expected:
"222"
"1\ 222\ .3\ .4"
Case 3 got/Expected:
"\{\ \[ipaddr\]=\"192.168.0.1/24\"\ \[address\]=\"192.168.0.1\"\
\[prefixlen\]=\"24\"\ \;\ \}"
"\{\ \[ipaddr\]=\"192.168.0.1/24\"\ \[address\]=\"192.168.0.1\"\
\[prefixlen\]=\"24\"\ \;\ \}"
Passed 2/4 tests.
The outputs for case 3 look identical -- I was using %s to print
them out, but switched to "%q", to ensure no hidden chars...
case 2 --
??? Why didn't it only change the 1 member?
RE: Bash crash
Hi all, Thank you all! The issue happens since we added a new process launched by a bash script. Before that, no "sbrk issues" were found and hundreds of process including scripts were running in my equipment. So it is hard for me to believe that there are RAM or sbrk issues already exist on my system. Also bash is used by more users world-wide, so ... I am being confused... The process named "com" launched by script command "com.sh start". Pls refer to the attached files. It looks easy, doesn't it? @Piotr, Sure. Every equipment has the possibility of the issue. -Original Message- From: Piotr Grzybowski [mailto:narsil...@gmail.com] Sent: 2015年10月21日 19:27 To: Kai Wang X Subject: Re: Bash crash hello, does the problem also appear on other pieces of equipment? I mean, different phisical machine, of the same sort? pg On Wed, Oct 21, 2015 at 4:29 AM, Kai Wang X wrote: > 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/ com.sh Description: com.sh
Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?
Bob Proulx wrote: Linda Walsh wrote: Where does the OS claim it is a file descriptor? --- 1) in the kernel documentation: file 'devices.txt: /dev/fd /proc/self/fd symbolicFile descriptors 2) ls -Ll shows the type of what the symlink points to: ls -Ll /dev/fd/ total 0 crw--w 1 law tty 136, 0 Oct 21 19:49 0 crw--w 1 law tty 136, 0 Oct 21 19:49 1 crw--w 1 law tty 136, 0 Oct 21 19:49 2 --- and 3) YOU claim it is a descriptor further down in this note: tmpname=<(sort /dev/null); ls -l "$tmpname" ls: cannot access /dev/fd/63: No such file or directory But as soon as the first commend is finished at the ';' then the descriptor will be closed and the path will evaporate. Therefore the ^ path won't exist for the second command. --- If you close a file-descriptor to a normal file it doesn't disappear. If it was deleted via 'rm' the name disappears immediately, and the only access to it is through the descriptor. In this case, closing the descriptor deletes the temporary name in the process's 'file descriptor' "/fd/". Normal filenames are not "auto-deleted" when you close an I/O handle to them. But if you use it for the ls command itself then it exists for that command. ls -l <(sort /dev/null) lr-x-- 1 rwp rwp 64 Oct 19 15:56 /dev/fd/63 -> pipe:[102059434] But only as a pointer to something one can do I/O on. You can't set any file attributes or metadata on "pipe:[]" It's not a real file somewhere.
Re: language inconsistency(wart) & RFE
Greg Wooledge wrote:
On Sat, Oct 17, 2015 at 08:55:31AM -0700, Linda Walsh wrote:
If I needed a way to declare something global, yes...
But what I am wanting is a way to allow changing the defaults
of the implicit variable creation (which could still be
explicitly declared with "-g" if one wanted their result to be
made global.
So you are basically saying you want all of your function variables
to be local
---
No... only ones where 'shopt -s auto_local' was in effect.
but you are too lazy to write 'local i j k' and you want
bash to do it for you?
local i j k doesn't define j as an array or k as a hash
or g (w/-g ) as a global or any case modification vars.
Not to mention your statement doesn't work:
function nint {
local i j k
for ((i=0; i<10; ++i)) ; do j+=i; k+=j ;done
echo "i=$i, j=$j, k=$k"
}
nint && echo "($i, $j, $k)"
i=10, j=ii, k=jj
(, , )
You declared them all the same, but at the end of the
function, j and k do not have integer values.
Trying to init them:
function nint {
local i=0 j=0 k=0
for ((i=0; i<10; ++i)) ; do
j+=i
k+=j
done
my -p i j k; echo "i=$i, j=$j, k=$k"
}
nint && echo "($i, $j, $k)"
declare -- i="10"
declare -- j="0ii"
declare -- k="0jj"
i=10, j=0ii, k=0jj
(, , )
---
Now we see that i & j & k all have the same
attributes ... yet only 'i' has an integer value.
If you could declare all the vars in 1 statement w/different types:
declare -i INT -a ARRAY -A HASH
---
That would be a huge improvement. But instead,if you
use a 'for' statement, without pre-declaring all the vars
used, you end up leaking variables:
function nint {
for ((i=0; i<10; ++i)) ; do
j+=i
k+=j
done
my -p i j k; echo "i=$i, j=$j, k=$k"
}
nint && echo "($i, $j, $k)"
declare -- i="10"
declare -- j="ii"
declare -- k="jj"
i=10, j=ii, k=jj
(10, ii, jj)
---
"leaking variables" into the external environment
is almost always considered bad-practice.
The default that bash encourages with its default behavior
is for all implicitly used vars in a function to be
leaked to the global level. From a program maintenance
and development standpoint, having such a horrible default
with no way to override it just seems really icky.
Also I think you are completely misrepresenting the dynamic variable
scope system that bash uses. Variables are not just global or local.
There's an entire stack of them. When you reference a variable (let's
say i) inside a function, bash searches up through the call stack
looking for a variable named i until it finds one.
Since functions cannot return values to their callers, the entire system
of "put values into an upper-scope variable so the caller can see them"
would break if your proposal of automatic localization were to be
adopted.
# Pick unbiased random number from 0 to N-1 ($1 = N)
# Returns value in variable r.
rand() {
local max=$((32768 / $1 * $1))
while (( (r=$RANDOM) >= max )); do :; done
r=$(( r % $1 ))
}
foo() {
local r
rand 6
echo "I rolled $((r+1))"
}
foo
# r is not visible here
Under your proposal, the variable r which is defined locally in foo, and
is up-scope-visible to rand (so that rand can put a return value into
it), would also be defined locally within r, so there would be no way to
return a value from rand to foo.
(If you want to attack "language warts", start with the inability to
return values from functions to their callers!)
