Re: Is there a special variable for the directory where the script is in?
pk a écrit : Peng Yu wrote: $0 gives the file name of the script. I could use several shell command to get the directory where the script is in. But I'm wondering if there is an easy-to-use variable that refers to the directory where the script is in? See this page: http://mywiki.wooledge.org/BashFAQ/028 This is well informed, very useful and very interesting page is considering the case where: - you want your widely distributed and very portable script to be called in any way from anywhere (including from a pipe from Mars). - hard-coding the location of your configuration files and libraries is not a problem. I am sure this is the most common case. But this is definitely not my case. Actually, my requirements are *the exact opposite*. For instance I do not want anyone to use my script but me. So I just do this instead: source $(dirname $0)/functions.sh The fact that it might break whenever someone else uses my script in a way I did not plan is a feature (in this respect, this code is even too robust).
Re: Is there a special variable for the directory where the script is in?
Marc a écrit :
source $(dirname $0)/functions.sh
I usually begin all my scripts with this beast:
absolutiseScripts() { SCRIPTS=$1 ; echo $SCRIPTS | grep -q ^/ ||
SCRIPTS=`dirname $2`/$SCRIPTS ; } ; absolutiseScripts `command -v $0`
`pwd`/. ; while [ -h $SCRIPTS ] ; do absolutiseScripts `readlink
$SCRIPTS` $SCRIPTS ; done ; SCRIPTS=`dirname $SCRIPTS`
I use it with bash on Mac OS X, FreeBSD, Linux, and it seems (just tested now
at work) that HP/UX 11 with its bare sh can handle it.
It does a lot of symlink-resolution, because I typically store my scripts in an
src/scripts directory, with symlinks from $HOME/bin/tagadatsointsoin to
$HOME/src/scripts/tagadatsointsoin.
--
Guillaume
Re: process substitution and trailing file descriptors
Ian wrote:
The manual suggests I could move and close file descriptors with
[n]digit-
but I would need the equivalent of
command1 (...)-
Digit might very well mean (just a) digit but here the process
substitution, of course, is replaced with /dev/fd/63, say, certainly
not a digit.
What about something like this (highly non-portable):
run_with_tee()
{
_run_with_tee (tee out) $@
}
_run_with_tee()
{
local fdpipeout=${1#/proc/self/fd/}; shift
# Redirect+close not to leak the extra pipe FD
$fdpipeout- $@
}
run_with_tee someCommand
Greg Wooledge wrote:
When the shortcuts are too short, you need to fall back to the original
tools. In this case, () is really just a shortcut for create a FIFO,
and open it. Doing so by hand should give you the manual control you
need. At the very least, you can tell bash which FD number to use when
you open the FIFO.
Yeah, but then you have the hassle to cleanup/delete the FIFO by yourself.
And leave tons of them behind in case of errors.
Re: Is there a special variable for the directory where the script is in?
On Fri, Feb 12, 2010 at 11:56:49AM +0100, Guillaume Outters wrote:
I usually begin all my scripts with this beast:
absolutiseScripts() { SCRIPTS=$1 ; echo $SCRIPTS | grep -q ^/ ||
SCRIPTS=`dirname $2`/$SCRIPTS ; } ; absolutiseScripts `command -v $0`
`pwd`/. ; while [ -h $SCRIPTS ] ; do absolutiseScripts `readlink
$SCRIPTS` $SCRIPTS ; done ; SCRIPTS=`dirname $SCRIPTS`
I use it with bash on Mac OS X, FreeBSD, Linux, and it seems (just tested now
at work) that HP/UX 11 with its bare sh can handle it.
Except that HP-UX 10.20 and HP-UX 11.11 don't have readlink(1).
(Maybe it's added in 11.2x? I don't know.)
Re: Is there a special variable for the directory where the script is in?
Greg a écrit : Except that HP-UX 10.20 and HP-UX 11.11 don't have readlink(1). (Maybe it's added in 11.2x? I don't know.) You're right. I must admit I made a concession to some GNU coreutils tools on the platform. I once used some ls -l $SCRIPTS | sed -e 's/.* - //' magic to replace it (and it worked two minutes ago on the HP-UX, just like it used to back in the old days). -- Guillaume
declare -c still undocumented.
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../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux teheran 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: declare: usage: declare [-aAfFilrtux] [-p] [name[=value] ...] mik...@teheran:~$ declare -c moo=moo; echo $moo Moo Repeat-By: run declare -c Fix: document in bash(1), document in usage:, add to builtin help.
Re: Circulate matches in command completion?
On 2/11/10 6:14 PM, Peng Yu wrote: bind 'set show-all-if-ambiguous On' bind 'TAB:menu-complete' I typed the above commands in the command line, but I still don't see the print out of all matches. Would you please let me know how to debug what is wrong? The combination of those two commands does exactly what you want in bash-4.1. Menu completion on previous versions of bash behaves differently. 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: Circulate matches in command completion?
On Fri, Feb 12, 2010 at 10:43 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/10 6:14 PM, Peng Yu wrote: bind 'set show-all-if-ambiguous On' bind 'TAB:menu-complete' I typed the above commands in the command line, but I still don't see the print out of all matches. Would you please let me know how to debug what is wrong? The combination of those two commands does exactly what you want in bash-4.1. Menu completion on previous versions of bash behaves differently. My bash is of the following version. I guess this is the reason what the command is not working? $ bash --version GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc.
Re: Is there a special variable for the directory where the script is in?
Greg Wooledge wrote:
That leaves names which contain -. The tricky part here is that we
can't easily tell whether an extra - is in the symbolic link or in
the target.
imadev:~$ ln -s tmp 'x - y'
imadev:~$ ln -s 'y - tmp' x
imadev:~$ ls -ld x*
lrwxr-xr-x 1 wooledgpgmr 8 Feb 12 09:28 x - y - tmp
lrwxr-xr-x 1 wooledgpgmr 3 Feb 12 09:28 x - y - tmp
However, there actually is enough information available to extract
the desired part. When we call ls -l, we're passing it the filename
we're resolving. So we already know the source name. Removing the
source name and the ' - ' which follows it should leave us with the
target name.
link=$(command ls -l -- $file; printf x)
link=${link%$'\nx'}
remove=$file -
file=${link#*$remove}
Your solution using the original filename is better but I thought I
would point out that the size of the target value is also displayed by
'ls -l'. In the above the value tmp is 3 characters and y - tmp
is 8 characters and that value is displayed in the size field. So
even without knowing the filename to be listed the result can be
parsed to extract the target name.
Bob
Re: Circulate matches in command completion?
On 2/12/10 11:47 AM, Peng Yu wrote: The combination of those two commands does exactly what you want in bash-4.1. Menu completion on previous versions of bash behaves differently. My bash is of the following version. I guess this is the reason what the command is not working? $ bash --version GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Yes, the bash-3.2 version of menu completion did not list completions. It would have helped if you had included version information in your original bug report. -- ``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: declare -c still undocumented.
On Feb 12, 2:10 am, Mikael Fridh fri...@gmail.com wrote:
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../bash -I../bash/include
-I../bash/lib -g -O2 -Wall
uname output: Linux teheran 2.6.31-19-generic #56-Ubuntu SMP Thu Jan
28 02:39:34 UTC 2010 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
declare: usage: declare [-aAfFilrtux] [-p] [name[=value] ...]
mik...@teheran:~$ declare -c moo=moo; echo $moo
Moo
Repeat-By:
run declare -c
Fix:
document in bash(1), document in usage:, add to builtin help.
Also, toggle case by word ${PARAMETER~PATTERN} and toggle case all $
{PARAMETER~~PATTERN} are undocumented.
Re: Is there a special variable for the directory where the script is in?
Am 12.02.2010 15:39, schrieb Greg Wooledge:
On Fri, Feb 12, 2010 at 02:53:39PM +0100, Bernd Eggink wrote:
I once wrote a more generic shell function for this purpose, see:
http://sudrala.de/en_d/shell-getlink.html
You note that it doesn't handle names containing -, which is true.
I'll get back to that at the end.
It also won't handle any name that ls -l will refuse to print out
correctly on any given system.
Also, there are three more cases that it can't handle. The first is
due to missing quotes in your command:
echo ${link##*- }
Without quotes, this will mangle all leading, trailing or repeated
whitespace. Easily fixed by adding the quotes. (There are a few
other cases of missing quotes too.)
Thanks. I knew there were some missing cases, but when I wrote it, I
didn't consider hardening the function against insane filenames worth
the effort.
However, it now begins to interest me if this is common practice. How
big is the probability to stumble upon such filenames is in real life?
Bernd
--
Bernd Eggink
http://sudrala.de
Re: Is there a special variable for the directory where the script is in?
Greg Wooledge wool...@eeg.ccf.org writes:
And testing:
imadev:~$ file=$HOME/x
imadev:~$ link=$(command ls -l -- $file; printf x)
imadev:~$ link=${link%$'\nx'}
imadev:~$ remove=$file -
imadev:~$ file=${link#*$remove}
This lacks a pair of quotes (${link#*$remove}). Testcase: 'x[a]' - 'y'.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: undefined reference to `__strtoll'
Hi, So how do I compile the 32-bit version of bash? Should I uninstall the GCC compiler I have and goto 3.4.6 like an earlier poster? -dave On Thu, Feb 11, 2010 at 16:43, Bob Proulx b...@proulx.com wrote: Greg Wooledge wrote: Dave Moore wrote: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc ... My version of GCC is gcc -v Using built-in specs. Target: hppa64-hp-hpux11.00 Configured with: ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host=hppa64-hp-hpux11.00 Thread model: single gcc version 4.0.0 Are you trying to compile a 32-bit executable or a 64-bit executable? A 32-bit compile should work okay. But a 64-bit compile /may/ have problems. You may be better off trying to compile a 32-bit executable. I don't have an HP-UX 11.00 machine to test on, but: I don't at this time either. I used to though. There is a known problem on HP-UX concerning 64-bit compiles. If the gcc installation is trying to use the system header files then this would probably trickle through. The default compilation mode is 32-bit and 32-bit builds compile okay. But a define in inttypes.h is upside-down and is broken in 64-bit mode. From coreutils notes I have the following patch to the HP-UX system files (use at your own risk) to fix the problem. --- /usr/include/inttypes.h.origThu May 30 01:00:00 1996 +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 @@ -489 +489 @@ -#ifndef __STDC_32_MODE__ +#ifndef __LP64__ As I recall in 64-bit mode all of the strtoull et al routines are broken without this fix. It might have eventually gotten fixed upstream in some later 11.x release by this late date but I don't know. But the problem as reported seems like it may be related. Bob
Re: undefined reference to `__strtoll'
How do I configure the linker to use the system linker instead of gnu LD?
I really appreciate the replies!
-dave
On Thu, Feb 11, 2010 at 15:49, Greg Wooledge wool...@eeg.ccf.org wrote:
On Thu, Feb 11, 2010 at 12:58:46PM -0500, Dave Moore wrote:
Machine: hppa2.0w
OS: hpux11.00
Compiler: gcc
Bash Version: 4.1
Patch Level: 0
I don't have an HP-UX 11.00 machine to test on, but:
I'm having trouble compiling bash on HP-UX 4.1. I can't figure out how
to
work around it. Basically, the version of HP-UX I'm running on doesn't
have
strtoll.
It's not supposed to, as far as I'm aware. __strtoll is an internal
libc thing.
bash-3.2# uname -sr
HP-UX B.11.11
bash-3.2# cd /usr/include
bash-3.2# find . -name '*.h' -exec grep strtoll /dev/null {} +
./inttypes.h:extern intmax_t __strtoll (const char *, char**, int);
./inttypes.h:extern intmax_t __strtoll ();
./inttypes.h:#define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)
There's no man page for strtoll on HP-UX 11.11 either.
So when I'm building, I see these errors:
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
-L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o
y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o
variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o
hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o
version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o
bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o
redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh
-lreadline -lhistory -lcurses -ltilde -lmalloc -lintl -ldl
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
If your linker is dumping core, you've got a problem with something more
fundamental than bash.
general.o(.text+0x334): In function `legal_number':
/home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to
`__strtoll'
braces.o(.text+0xae4): In function `brace_expand':
/home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to
`__strtoll'
./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax':
./printf.def:998: undefined reference to `__strtoll'
make: *** [bash] Error 1
This also points to a problem with your toolchain. Broken header files,
broken linker, who knows
My version of GCC is
gcc -v
Using built-in specs.
Target: hppa64-hp-hpux11.00
Configured with: ../src/configure --enable-languages=c,c++
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
--with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
--host=hppa64-hp-hpux11.00
Thread model: single
gcc version 4.0.0
I'm using:
bash-3.2# gcc -v
Reading specs from /usr/local/lib/gcc/hppa1.1-hp-hpux11.11/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --with-gnu-as
--with-as=/usr/local/bin/as
Thread model: single
gcc version 3.4.6
(Yeah, I know, an hppa1.1 machine...! That was not easy to get gcc
bootstrapped onto.)
I don't know if there's a specific problem with gcc 4.0.0 on HP-UX 11.00.
That's an awful lot of zeros, though. Things with dot zero on the end
of them tend to scare me a bit.
I see you're using GNU ld, which shouldn't be required on this platform.
And also that ld is dumping core. You might try upgrading your GNU
binutils if you want to continue using GNU ld (or even just rebuilding
your current version); or you might try configuring gcc to use the
system's linker.
In any case, I'm pretty sure it's not a bash bug that you're running into.
(If/when you run into a problem with vsnprintf, *that* is a bash bug,
fixed in one of the 4.1 patches. You might grab the bash patches before
your next attempt, after you get your toolchain working.)
Re: undefined reference to `__strtoll'
Bob, I didn't read this carefully -- should I try the patch you suggested before we do anything else? -dave On Thu, Feb 11, 2010 at 16:43, Bob Proulx b...@proulx.com wrote: Greg Wooledge wrote: Dave Moore wrote: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc ... My version of GCC is gcc -v Using built-in specs. Target: hppa64-hp-hpux11.00 Configured with: ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host=hppa64-hp-hpux11.00 Thread model: single gcc version 4.0.0 Are you trying to compile a 32-bit executable or a 64-bit executable? A 32-bit compile should work okay. But a 64-bit compile /may/ have problems. You may be better off trying to compile a 32-bit executable. I don't have an HP-UX 11.00 machine to test on, but: I don't at this time either. I used to though. There is a known problem on HP-UX concerning 64-bit compiles. If the gcc installation is trying to use the system header files then this would probably trickle through. The default compilation mode is 32-bit and 32-bit builds compile okay. But a define in inttypes.h is upside-down and is broken in 64-bit mode. From coreutils notes I have the following patch to the HP-UX system files (use at your own risk) to fix the problem. --- /usr/include/inttypes.h.origThu May 30 01:00:00 1996 +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 @@ -489 +489 @@ -#ifndef __STDC_32_MODE__ +#ifndef __LP64__ As I recall in 64-bit mode all of the strtoull et al routines are broken without this fix. It might have eventually gotten fixed upstream in some later 11.x release by this late date but I don't know. But the problem as reported seems like it may be related. Bob
Re: undefined reference to `__strtoll'
Dave Moore wrote: I didn't read this carefully -- should I try the patch you suggested before we do anything else? Yes. (Dave and I had some private email exchange where we discussed the contents of inttypes.h on his system. I see that he is suffering from the bug that I described.) The problem is that strtoimax and strtoumax are defined as macros in the inttypes.h file and they are not working in 64-bit mode. Here is a summary. grep strtoumax /usr/include/inttypes.h #ifndef __STDC_32_MODE__ #define strtoumax(__a, __b, __c) __strtoll(__a, __b, __c) #else #define strtoumax(__a, __b, __c) (intmax_t)strtol(__a, __b, __c) #endif One is for 32-bit and one is for 64-bit. For 32-bit compiles you want the __strtoll version and for 64-bit compiles you want the strtol version. Unfortunately they are erroneously reversed in that header and that breaks 64-bit compiles because in 64-bit mode you get the __strtoll symbol which is available only in the 32-bit libraries. The result is seen as an unresolved reference in the linker output: bash-4.1/braces.c:395: undefined reference to `__strtoll' With line bash-4.1/braces.c:395 being: tr = strtoimax (rhs, ep, 10); I recommend fixing this by editing the system file and correcting the define. That would help much software going forward. Since you are using gcc it will have a private version of this file. At the least you should be able to modify it and get relief when using gcc. In your file /usr/local/pa20_64/lib/gcc/hppa64-hp-hpux11.00/4.0.0/include/inttypes.h change line 508 from __STDC_32_MODE__ to __LP64__ and then recompile everything and I think you will see some relief from the ld: Unsatisfied symbol __strtoull in file ... (HP-UX cc) and undefined reference to `__strtoll' (gcc) problem. To fix this for the native HP-UX C compiler in 64-bit mode make the same change to the /usr/include/inttypes.h file. I don't know about the ld core dump though. That shouldn't happen regardless. Hope this helps! Bob
