autoconf 2.69?
Support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. bash uses an earlier version of autoconf, preventing its being built. Is there any plan to upgrade to version 2.69. Looking at devel branch it is using 2.68. RR
rename directory and internal pwd command.
Hello, I am useig bash-3.2.25 on CentOS. $ bash --version bash --version GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. 1. Go to directory ~/src. $ cd ~/src 2. Rename the directory to ~/src-old. $ mv ~/src ~/src-old 3. Invoke pwd command. Then print /home/asou/src by pwd command. $ pwd /home/asou/src 4. Invoke /bin/pwd command. Then print /home/asou/src-old. $ /bin/pwd /home/asou/src-old Is this a bug of internal pwd command? -- ASOU Masato
Re: autoconf 2.69?
On Wednesday 27 March 2013 11:44:32 Roman Rakus wrote:
> Support for the ARM 64 bit CPU architecture (aarch64) was introduced in
> autoconf 2.69. bash uses an earlier version of
> autoconf, preventing its being built.
are you talking about config.{sub,guess}, or something else ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: rename directory and internal pwd command.
Masato Asou wrote: > 1. Go to directory ~/src. > $ cd ~/src > 2. Rename the directory to ~/src-old. > $ mv ~/src ~/src-old > 3. Invoke pwd command. Then print /home/asou/src by pwd command. > $ pwd > /home/asou/src > 4. Invoke /bin/pwd command. Then print /home/asou/src-old. > $ /bin/pwd > /home/asou/src-old > > Is this a bug of internal pwd command? This is an intentional feature. Bash tracks your present working directory as changed by the cd command in the PWD variable. The pwd command prints that variable. When you arrived at the location $HOME/src the location was stored in the PWD variable. Moving it out from under your current process had no effect on the value of the PWD variable. Calling pwd prints the content of PWD variable. In the pwd documentation this is described briefly along with the -L and -P options for "logical" and "physical" behavior. By default bash follows the logical chain of directories when performing commands which change the current directory. The logical status is how you got there. The intention is to make symbolic links invisible to the user. You could cd to a symlinked directory and then 'cd ..' would back you one logical directory out and return you to where you were. Using a physical view the directory change through a symlink would place you in the new directory and a 'cd ..' would take you up from there. If you 'set -o physical' then bash will use the canonical physical structure of the file system when performing commands which change directories. Personally I dislike the problems associated with the shell's logical view and always have 'set -o physical' in my .bashrc file so that I see the canonical physical file system directory structure. The logical view is a thin facade that is too easily broken. But the majority of users seem to prefer the logical view just the same. Bob
Re: autoconf 2.69?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/27/13 1:07 PM, Mike Frysinger wrote:
> On Wednesday 27 March 2013 11:44:32 Roman Rakus wrote:
>> Support for the ARM 64 bit CPU architecture (aarch64) was introduced in
>> autoconf 2.69. bash uses an earlier version of
>> autoconf, preventing its being built.
>
> are you talking about config.{sub,guess}, or something else ?
He's talking about config.{sub,guess}. I updated them from the autoconf
2.69 versions a couple of days ago and they will be in the next snapshot.
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFTNFAACgkQu1hp8GTqdKtvcgCgkop/nvrHqCFu4Id5Z2qbKre0
NXMAnAmsjkGvZsOy6/U39zhJPcZOzr2X
=F5h8
-END PGP SIGNATURE-
weird problem -- path interpretted/eval'd as numeric expression
Not sure if this is the correct forum for this, as I am very uncertain that it is a bash-bug and am more inclined to believe it is some odd interpretation causing my code to go hay-wire in this instance. So if I should move this to another discussion location, I'm fine with that -- I'm just trying to figure out why something of the form include lib/Util/Needroot.shh where include is a function the name of a file in my path (or an alias to define the function)... /home/law/bin/recycle_space: line 7: lib/Util/needroot.shh: division by 0 (error token is "/needroot.shh") If I try: changing the path to: Util/needroot.shh I get: /home/law/bin/recycle_space: line 7: Util/needroot.shh: syntax error: invalid arithmetic operator (error token is ".shh") If I add double quotes around the pathname (as I didn't think they should be needed in this case), it makes no difference. I get the same message as in the first case (div by 0) It might be thought that the issue is complicated by the fact that needroot.shh will re-execute the original script with 'sudo' if it is run by a non-root user, but running the script (recycle_space) AS root (when the 'needroot.shh' _doesn't_ re-execute itself, also results in the same error. Are there any 'odd circumstances' where an argument to a function is automatically eval'd as an integer expression instead of just being passed as a string? This has been a problem for several months, just that it IS work-around able and the multiple attempts at re-following the execution flow haven't yielded anything new -- just more cryptic symptoms...(like the line the 'include is on, isn't even on line 7, it's on line 14...minor things like that... ;-/). Ideas?
Re: weird problem -- path interpretted/eval'd as numeric expression
On Wed, Mar 27, 2013 at 11:29:38AM -0700, Linda Walsh wrote: > include lib/Util/Needroot.shh > > where include is a function the name of a file in my path (or an alias > to define the function)... > > > /home/law/bin/recycle_space: line 7: lib/Util/needroot.shh: division by > 0 (error token is "/needroot.shh") We would need to see the definition of the "include" function, and the contents of the file that it's presumably sourcing or whatever.
Re: weird problem -- path interpretted/eval'd as numeric expression
Greg Wooledge wrote:
> We would need to see the definition of the "include" function, and the
> contents of the file that it's presumably sourcing or whatever.
>
Working on packaging, but to answer your immediate questions:
Assuming attachments work, 'include' is in ~/bin
Note, some of these files are "works in progress, so some things
aren't finished...which will be obvious)...
recycle space uses a non-broken version of 'rm' that
really does a depth-first removal of files and doesn't
violate depth-first order for special cases -- but you don't need
that to see this problem (it never gets there and would only
run if you used "-e")
The function is defined in /etc/local/aliases.sh
There are several other files needed for the whole mess -- am working on
putting them in a dir structure that can be packaged...but this
should give you the initial files. If I forgot any other files
that are needed right away, I can send those off, but getting close
to needing to take a break, so not sure how long packaging everything
will take...
There are mentions of cygwin in the scripts as I try to maintain
a common set of scripts that runs on either cygwin or linux, but
this script is run on linux.
Thanks for any hints and patience...
#!/bin/bash
#echo "include:2"
shopt -s expand_aliases
alias dcl=declare
alias 1>&2
dcl -x _SPATH
dcl -xa _FPATH
dcl -xA _INC
function pathof {
local prog="$1"
local path
for path in $(IFS=:;echo $PATH );do
path="$path/$prog"
if [[ -f $path && -x $path ]]; then echo "$path"; return 0; fi
done
echo "$prog: not found" >&2
}
function _include_h {
# [[ ${0##*/} == include ]] && { exec "$@" ; }
[[ $1 ]] || return 1
dcl fnc="$1"
[[ $PATH != ${_SPATH:-} ]] && {
unset _FPATH
dcl -xa _FPATH=( $(IFS=:;echo $PATH) )
unset _SPATH; dcl -x _SPATH="$PATH"
}
if [[ ! ${_INC["$fnc"]:-""} ]]; then
for pw in "${_FPATH[@]}"; do
if [[ -r $pw/$fnc ]]; then
printf "%s
" "source \"$pw/$fnc\"" &&
_INC["$fnc"]="$pw/$fnc" && return 0
fi
done
echo "ERROR: Missing \"$fnc\" in \$PATH" >&2
exit 2
fi
}
export -f _include_h
read alias_def <<'_alias_def_end_'
alias include='eval "$( _include_h "$1")"'
_alias_def_end_
export
__GLOBAL_ALIASES__="$alias_def${__GLOBAL_ALIASES__:+";$__GLOBAL_ALIASES__"}"
# test if initial include -- if so, restart with aliases defined...
[[ ${0##*/} == include ]] && { exec "$@" ; }
# else include the arg
include "$@"
# vim: ts=2 sw=2
#!/bin/bash -x
#full trace support:
export
PS4='>>${BASH_SOURCE:+${BASH_SOURCE[0]}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}>
'
# gvim=:SetNumberAndWidth #rm 'no' to activate in gvim, '=:' is not error
_prgpth="${0:?}"; _prg="${_prgpth##*/}"; _prgdr="${_prgpth%/$_prg}"
[[ -z $_prgdr || $_prgdr == . || $_prg == $_prgdr ]] && _prgdr="$PWD"
export PATH="$_prgdr:$_prgdr/lib:$PATH"
#printf "prgpth=%s, prg=%s, prgdr=%s\n" "$_prgpth" "$_prg" "$_prgdr"
shopt -s expand_aliases extglob sourcepath xpg_echo; set -o pipefail
#source {errnos,stdlib}.shlib
echo lib/Util/needroot.shh
include "lib/Util/needroot.shh"
# vim: ts=2 sw=2
Recycle_pat='\.recycle$'
function recycle_bins {
locate -e /.recycle|grep $Recycle_pat
}
Ls="$(type -P ls)"
function empty_dir {
local d="$1"
local -i f="$($Ls -A1 "$1"|wc -l)"
return $f
}
m1="Space Consumed in Recycle bins:"
m2="Emptying recycle bins..."
m3="Expiring Recycle bins..."
msg="$m1"
declare -i remove=0 quiet=0 expire=0
declare -a args
while [[ $# > 0 ]]; do
if [[ $1 == "-e" || $1 == "--empty" ]]; then remove=1; msg="$m2"
elif [[ $1 == "-x" || $1 == "--expire" ]]; then
shift && expire=${1:?};
msg="$m3"
elif [[ $1 == "-q" || $1 == "--quiet" ]]; then quiet=1
fi
shift
done
function usage {
shopt -s xpg_echo
local -a msg=(
" recycle_space-- manage 'recycling space'\n\n"
" (no args) -- display space taken by all recycle bins found\n"
" TBD -e -- empty all recycle bins found\n"
" TBD -x -- eXpire files older than 'weeks' from bins\n"
" -q -- suppress this message\n\n")
echo -e "${msg[@]}"
}
#if ((remove || expire >-1)); then
# printf "option not yet done...\n"
# exit 0;
#fi
((!quiet)) && usage
printf "%s\n" "$msg"
{
while read dir ; do
empty_dir "$dir" && continue
if ((remove)) ; then
( cd "$dir" && rm --one-file-system -fr .)
elif ((expire)); then :
else
printf " %4s %s\n" "$(sudo du -sh "$dir"|cut -f1)"
"$dir"
fi
Re: weird problem -- path interpretted/eval'd as numeric expression
On Wed, Mar 27, 2013 at 12:17:21PM -0700, Linda Walsh wrote: > dcl -xa _FPATH Arrays cannot be exported. The bash manual explicitly says so: Array variables may not (yet) be exported. > } | ( ((!(remove||expire))) && hsort -s || cat) Use of the && and || operators together as a "shorthand" for if/then/else is dangerous. If the hsort command returns failure, the cat command will ALSO be executed. http://mywiki.wooledge.org/BashPitfalls#pf22 Use an if command instead: ... } | if (( !(remove||expire) )); then hsort -s; else cat; fi Or even better: ... } | if ((remove||expire)); then cat; else hsort -s; fi Apart from those two things, I didn't really read the code. It was quite a bit larger than I expected. Those two problems were just the first ones I found. You may find it helpful to use "set -x" on the section of the code from which the error message is originating. Seeing the expanded command that generates the message may be sufficient to identify the error (assuming it's your error and not bash's). If it turns out to be a bug in bash, then having a smaller piece of code that can reproduce the bug will be useful.
Re: weird problem -- path interpretted/eval'd as numeric expression
Greg Wooledge wrote:
> On Wed, Mar 27, 2013 at 12:17:21PM -0700, Linda Walsh wrote:
>> dcl -x _SPATH
>> dcl -xa _FPATH
>> dcl -xA _INC
>
> Arrays cannot be exported. The bash manual explicitly says so:
>
> Array variables may not (yet) be exported.
===
It is there for the 'yet' part. In "aliases.sh" which
defines the 'include' function, we see:
declare -A _INC
export _INC
function include {
[[ $1 ]] || return 1
local fnc="$1"
[[ $PATH != ${_SPATH:-} || ${#_FPATH[@]} -lt 1 ]] && {
unset _FPATH
local -xa _FPATH=( $(IFS=:;echo $PATH) )
export _SPATH="$PATH"
}
if [[ -z ${_INC["$fnc"]:-} ]]; then
for pw in "${_FPATH[@]}"; do
[[ ${pw:0-1:1} != / ]] && pw+='/'
local fn="${pw}${fnc}"
if [[ -r $fn || -r $fn.shh && fn+=".shh" ]]; then
source "$fn" || {
stat=$?
echo "Error: include of \"$fnc\" did not return 0 status"
return $stat
}
_INC["$fnc"]="$fn"
return 0
fi
done
echo "Cannot find \"$fnc\" in \"$PATH\"" >&2
exit 2
fi
}
export -f include
--
I.e. you *CAN* export a function -- and this function reconstructs
the array from SPATH if FPATH is not defined or if PATH has changed.
>
>> } | ( ((!(remove||expire))) && hsort -s || cat)
>
> Use of the && and || operators together as a "shorthand" for if/then/else
> is dangerous. If the hsort command returns failure, the cat command
> will ALSO be executed.
It is intentional that cat execute if hsort returns
failure. FWIW, I was updating that section too try to use 'sort -h',
instead of hsort -- hsort was written before sort -h was available, though
sort -h doesn't produce a summary line at the end, so it's not
quit as nice.
But the point of that statement was that if you are *not doing*
remove or expire, then try to produce h-sorted (sort -h) output,
if that fails, then do 'cat'...
>
> http://mywiki.wooledge.org/BashPitfalls#pf22
>
> Use an if command instead:
>
> ... } | if (( !(remove||expire) )); then hsort -s; else cat; fi
> Or even better
> ... } | if ((remove||expire)); then cat; else hsort -s; fi
Neither of those will do what the original does -- which
is to execute cat as a fallback for hsort -- i.e. this design
was intentional.
>
> Apart from those two things, I didn't really read the code. It was
> quite a bit larger than I expected. Those two problems were just the
> first ones I found.
If it was easy, it wouldn't have stumped me for
several months...
>
> You may find it helpful to use "set -x" on the section of the code from
> which the error message is originating.
I did , that's why I have the PS4 statement in there... but I can't
make heads nor tails of the output...
recycle_space
>>~/.bash_env#7> [[ -n '' ]]
>>~/.bash_env#7> [[ -O /tmp/debug_local ]]
>>~/.bash_env#11> : /home/law/.bash_env
>>~/.bash_env#12> [[ -z 1 ]]
>>~/bin/recycle_space#4> export
>>'PS4=>>${BASH_SOURCE:+${BASH_SOURCE[0]}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}>
>> '
>>~/bin/recycle_space#4>
>>PS4='>>${BASH_SOURCE:+${BASH_SOURCE[0]}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}>
>> '
>>/home/law/bin/recycle_space#7> _prgpth=/home/law/bin/recycle_space
>>/home/law/bin/recycle_space#7> _prg=recycle_space
>>/home/law/bin/recycle_space#7> _prgdr=/home/law/bin
>>/home/law/bin/recycle_space#8> [[ -z /home/law/bin ]]
>>/home/law/bin/recycle_space#8> [[ /home/law/bin == . ]]
>>/home/law/bin/recycle_space#8> [[ recycle_space == /home/law/bin ]]
>>/home/law/bin/recycle_space#9> export
>>PATH=/home/law/bin:/home/law/bin/lib:.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/dell/srvadmin/bin:/usr/sbin:/home/law/bin/lib:/etc/local/func_lib:/home/law/lib
>>/home/law/bin/recycle_space#9>
>>PATH=/home/law/bin:/home/law/bin/lib:.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/dell/srvadmin/bin:/usr/sbin:/home/law/bin/lib:/etc/local/func_lib:/home/law/lib
>>/home/law/bin/recycle_space#11> shopt -s expand_aliases extglob sourcepath
>>xpg_echo
>>/home/law/bin/recycle_space#11> set -o pipefail
>>/home/law/bin/recycle_space#13> echo lib/Util/needroot.shh
lib/Util/needroot.shh
>>/home/law/bin/recycle_space#14> include lib/Util/needroot.shh
>>#0(include)> [[ -n lib/Util/needroot.shh ]]
>>#1(include)> local fnc=lib/Util/needroot.shh
>>#2(include)> [[
>>/home/law/bin:/home/law/bin/lib:.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/dell/srvadmin/bin:/usr/sbin:/home/law/bin/lib:/etc/local/func_lib:/home/law/lib
>> != '' ]]
>>#3(include)> unset _FPATH
>>#4(include)> _FPATH=($(IFS=:;echo $PATH))
>>>#4(include)> IFS=:
>>>#4(include)> echo /home/law/bin /home/law/
Re: weird problem -- path interpretted/eval'd as numeric expression
On Wed, Mar 27, 2013 at 01:25:53PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> > Arrays cannot be exported. The bash manual explicitly says so:
> >
> > Array variables may not (yet) be exported.
> ===
> It is there for the 'yet' part. In "aliases.sh" which
> defines the 'include' function, we see:
The word "yet" in the manual simply means that a FUTURE version of bash
may be able to do so. It does NOT mean "it will work if you write things
with a bunch of extra complexity".
> declare -A _INC
> export _INC
Associative arrays can't be exported either.
> @ line 9 in the function there is:
> if [[ -z ${_INC["$fnc"]:-} ]]; then
> ...
> and "$fnc" = lib/Utils/needroot.shh -- i.e. it's acting like
> it is evaluating "$fnc" without the double quotes -- and treating
> it like an integer expression.
>
> But _INC is a *HASH* (not a numeric) array...
>
> Could that be what is happening?
What makes you so sure it's an associative array at that point? Is it
something you inherited through the environment and assumed would be
treated as an associative array even though the manual says you can't
export arrays?
Try doing "declare -p _INC" right before that, to see what bash thinks
it is.
Also, try limiting the use of -x just to specific *regions* of the code
so you can pinpoint exactly where the error is happening, since you seem
to be unsure. Debugging the wrong chunk of code is a great way to waste
a lot of time.
Re: weird problem -- path interpretted/eval'd as numeric expression
Greg Wooledge wrote: > On Wed, Mar 27, 2013 at 01:25:53PM -0700, Linda Walsh wrote: >> Greg Wooledge wrote: >>> Arrays cannot be exported. The bash manual explicitly says so: >>> >>> Array variables may not (yet) be exported. >> === >> It is there for the 'yet' part. In "aliases.sh" which >> defines the 'include' function, we see: > > The word "yet" in the manual simply means that a FUTURE version of bash > may be able to do so. It does NOT mean "it will work if you write things > with a bunch of extra complexity". > >> declare -A _INC >> export _INC > > Associative arrays can't be exported either. --- Yeah, but they seem to get propagated anyway, I must save it somewhere like I do _FPATH... i.e. each include adds teh included script into the INC array so I don't try to re-include it. Note after I change the PATH, the _FPATH array is automatically updated as well Ishtar:law> include stdalias.shh declare -Ax _INC='()' declare -ax _FPATH='([0]="." [1]="/sbin" [2]="/usr/local/sbin" [3]="/home/law/bin" [4]="/usr/local/bin" [5]="/usr/bin" [6]="/bin" [7]="/usr/bin/X11" [8]="/usr/X11R6/bin" [9]="/usr/games" [10]="/opt/kde3/bin" [11]="/usr/lib/mit/bin" [12]="/usr/lib/mit/sbin" [13]="/opt/dell/srvadmin/bin" [14]="/usr/sbin" [15]="/home/law/bin/lib" [16]="/etc/local/func_lib" [17]="/home/law/lib")' Ishtar:law> PATH=~/bin/lib:$PATH Ishtar:law> include stdlib.shh declare -Ax _INC='([stdalias.shh]="/home/law/bin/lib/stdalias.shh" )' declare -ax _FPATH='([0]="/home/law/bin/lib" [1]="." [2]="/sbin" [3]="/usr/local/sbin" [4]="/home/law/bin" [5]="/usr/local/bin" [6]="/usr/bin" [7]="/bin" [8]="/usr/bin/X11" [9]="/usr/X11R6/bin" [10]="/usr/games" [11]="/opt/kde3/bin" [12]="/usr/lib/mit/bin" [13]="/usr/lib/mit/sbin" [14]="/opt/dell/srvadmin/bin" [15]="/usr/sbin" [16]="/home/law/bin/lib" [17]="/etc/local/func_lib" [18]="/home/law/lib")' # I execute a 2nd bash, but notice -- INC and FPATH were both propagated to the child and both # are of the correct type (so guess that wasn't an explanation) Unfortunately, if I try to include needroot, it tries to re-exec the original program, which doesn't work so well in an interactive shell... ;-) Ishtar:law> bash User law's .bashrc called 2nd time Ishtar:law> include stdlib.shh declare -Ax _INC='([stdlib.shh]="/home/law/bin/lib/stdlib.shh" [stdalias.shh]="/home/law/bin/lib/stdalias.shh" )' declare -ax _FPATH='([0]="/home/law/bin/lib" [1]="." [2]="/sbin" [3]="/usr/local/sbin" [4]="/home/law/bin" [5]="/usr/local/bin" [6]="/usr/bin" [7]="/bin" [8]="/usr/bin/X11" [9]="/usr/X11R6/bin" [10]="/usr/games" [11]="/opt/kde3/bin" [12]="/usr/lib/mit/bin" [13]="/usr/lib/mit/sbin" [14]="/opt/dell/srvadmin/bin" [15]="/usr/sbin" [16]="/home/law/bin/lib" [17]="/etc/local/func_lib" [18]="/home/law/lib")' declare -Ax _INC='([stdlib.shh]="/home/law/bin/lib/stdlib.shh" [stdalias.shh]="/home/law/bin/lib/stdalias.shh" )' declare -ax _FPATH='([0]="/home/law/bin/lib" [1]="." [2]="/sbin" [3]="/usr/local/sbin" [4]="/home/law/bin" [5]="/usr/local/bin" [6]="/usr/bin" [7]="/bin" [8]="/usr/bin/X11" [9]="/usr/X11R6/bin" [10]="/usr/games" [11]="/opt/kde3/bin" [12]="/usr/lib/mit/bin" [13]="/usr/lib/mit/sbin" [14]="/opt/dell/srvadmin/bin" [15]="/usr/sbin" [16]="/home/law/bin/lib" [17]="/etc/local/func_lib" [18]="/home/law/lib")'
Re: autoconf 2.69?
On Wednesday 27 March 2013 14:02:57 Chet Ramey wrote:
> On 3/27/13 1:07 PM, Mike Frysinger wrote:
> > On Wednesday 27 March 2013 11:44:32 Roman Rakus wrote:
> >> Support for the ARM 64 bit CPU architecture (aarch64) was introduced in
> >> autoconf 2.69. bash uses an earlier version of
> >> autoconf, preventing its being built.
> >
> > are you talking about config.{sub,guess}, or something else ?
>
> He's talking about config.{sub,guess}. I updated them from the autoconf
> 2.69 versions a couple of days ago and they will be in the next snapshot.
that's what i figured. i don't see why any distro would care what config.
{sub,guess} file gets shipped with package tarballs. any sane package manger
should be transparently replacing them with the latest CVS snapshot from the
GNU config project. leaving it to each package maintainer to manually update
it is ridiculous.
not that i'm against upstream people from updating their autotool versions.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: autoconf 2.69?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/27/13 6:29 PM, Mike Frysinger wrote: > not that i'm against upstream people from updating their autotool versions. Sure, but honestly it's not the highest thing on my list. - -- ``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 v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFThjEACgkQu1hp8GTqdKs+GgCeJWy6G9b61aROQhiwLvtWN89d vwIAoJ5K00THHXCZsAda20tcc4fcsWua =/4ac -END PGP SIGNATURE-
Re: rename directory and internal pwd command.
From: Bob Proulx Date: Wed, 27 Mar 2013 11:20:35 -0600 > Masato Asou wrote: >> 1. Go to directory ~/src. >> $ cd ~/src >> 2. Rename the directory to ~/src-old. >> $ mv ~/src ~/src-old >> 3. Invoke pwd command. Then print /home/asou/src by pwd command. >> $ pwd >> /home/asou/src >> 4. Invoke /bin/pwd command. Then print /home/asou/src-old. >> $ /bin/pwd >> /home/asou/src-old >> >> Is this a bug of internal pwd command? > > This is an intentional feature. Bash tracks your present working > directory as changed by the cd command in the PWD variable. The pwd > command prints that variable. When you arrived at the location > $HOME/src the location was stored in the PWD variable. Moving it out > from under your current process had no effect on the value of the PWD > variable. Calling pwd prints the content of PWD variable. Thank you for your careful comment. > In the pwd documentation this is described briefly along with the -L > and -P options for "logical" and "physical" behavior. By default bash > follows the logical chain of directories when performing commands > which change the current directory. The logical status is how you got > there. The intention is to make symbolic links invisible to the user. > You could cd to a symlinked directory and then 'cd ..' would back you > one logical directory out and return you to where you were. Using a > physical view the directory change through a symlink would place you > in the new directory and a 'cd ..' would take you up from there. > If you 'set -o physical' then bash will use the canonical physical > structure of the file system when performing commands which change > directories. Sorry, I forgot to confirm the man bash. > Personally I dislike the problems associated with the shell's logical > view and always have 'set -o physical' in my .bashrc file so that I > see the canonical physical file system directory structure. I also agree with your opinion. > The > logical view is a thin facade that is too easily broken. But the > majority of users seem to prefer the logical view just the same. Thanks. -- ASOU Masato
Re: Assignments preceding "declare" affect brace and pathname expansion.
On Tuesday, March 26, 2013 08:33:52 PM Chet Ramey wrote:
Thank you. I'm familiar with the declaration commands. It's issue 7, not TC1.
> arguments are expanded as normal and then treated as the command
> does its arguments.
Are you saying here that even when a declaration command is _not_ identified,
that it's still correct for word expansions to not follow the usual rules for
regular non-declaration commands?
Hopefully my examples were clear. What I don't understand is this:
# This is correctly recognized
$ touch 'a=( x )'
$ declare a=( * )
$ echo "$a"
a=( x )
# This should either be like above, or fail as below.
$ _= declare a=( * )
$ echo "$a"
( x )
# This does what I expect for unrecognized declaration commands.
$ cmd=declare
$ "$cmd" a=( * ); echo "$a"
-bash: syntax error near unexpected token `('
If it's true that an assignment prefix causes bash to not recognize
declaration commands (which is unfortunate IMO), then you would expect the 2nd
case above to be the same as the 3rd case. Instead, it's not wordsplitting and
not failing due to the () metacharacters, and using sort of a hybrid of the
two.
--
Dan Douglas
