Issue with errtrace
Hi all,
Recently upgraded to 3.2 and noticed some differences in a lot of my
scripts, consider the following example:
#!/bin/bash
trap error_reporter ERR
set -o errexit
set -o errtrace
set -o nounset
set -o pipefail
logf_error=/dev/null
function _exit
{
local -ri retval="${1:-$?}"
exit ${retval}
}
function error_reporter {
local -ri retval=$?
#echo "Error in script setup. Exiting with error value ${retval}."
local -i i=0
#echo "Function call stack:" >&2
while caller $i >&2; do (( i++ )); done
_exit ${retval}
}
function echo_ { #this is called as a $(command)
#a subcommand might return with 1 in the script, but in most cases it is
not a problem.
#At least in our scripts there are a lot of cases like this where the error
is handled afterwards
echo "" | grep b
echo "Execution continues"
}
echo "Turning off errtrace"
set +o errtrace
var=$(echo_)#calling as a $(command)
echo $var
echo "Turning on errtrace"
set -o errtrace
echo "Next command will fail in bash3.2"
var=$(echo_)#calling as a $(command)
echo $var
Doesnt work right on 3.2
Output from 3.0
root@atrcus365:/# /tmp/test
/tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
Execution continues
root@atrcus365:/# echo $BASH_VERSION
echo $BASH_VERSION
3.00.16(1)-release
root@atrcus365:/#
Output from 3.2
root@atmwsnfd:/# /tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
26 echo_ /tmp/test
42 main /tmp/test
42 main /tmp/test
root@atmwsnfd:/# echo $BASH_VERSION
3.2.51(1)-release
root@atmwsnfd:/#
Could anyone point me in correct direction on this one ?
Regards
Dave
bash 3.2 vs 3.0
Hi all,
Recently upgraded to 3.2 and noticed some differences in a lot of my
scripts, consider the following example:
#!/bin/bash
trap error_reporter ERR
set -o errexit
set -o errtrace
set -o nounset
set -o pipefail
logf_error=/dev/null
function _exit
{
local -ri retval="${1:-$?}"
exit ${retval}
}
function error_reporter {
local -ri retval=$?
#echo "Error in script setup. Exiting with error value ${retval}."
local -i i=0
#echo "Function call stack:" >&2
while caller $i >&2; do (( i++ )); done
_exit ${retval}
}
function echo_ { #this is called as a $(command)
#a subcommand might return with 1 in the script, but in most cases it is
not a problem.
#At least in our scripts there are a lot of cases like this where the error
is handled afterwards
echo "" | grep b
echo "Execution continues"
}
echo "Turning off errtrace"
set +o errtrace
var=$(echo_)#calling as a $(command)
echo $var
echo "Turning on errtrace"
set -o errtrace
echo "Next command will fail in bash3.2"
var=$(echo_)#calling as a $(command)
echo $var
Doesnt work right on 3.2
Output from 3.0
root@atrcus365:/# /tmp/test
/tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
Execution continues
root@atrcus365:/# echo $BASH_VERSION
echo $BASH_VERSION
3.00.16(1)-release
root@atrcus365:/#
Output from 3.2
root@atmwsnfd:/# /tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
26 echo_ /tmp/test
42 main /tmp/test
42 main /tmp/test
root@atmwsnfd:/# echo $BASH_VERSION
3.2.51(1)-release
root@atmwsnfd:/#
Could anyone point me in correct direction on this one ?
Regards
Dave
core/loop vi mode when '.' used to repeat a replace
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd4.8 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd4.8' -DCONF_MACHTYPE='i386-unknown-freebsd4.8' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=pentiumpro uname output: FreeBSD base686.home.org 4.8-RELEASE FreeBSD 4.8-RELEASE #14: Thu Sep 8 12:45:15 CDT 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/base686 i386 Machine Type: i386-unknown-freebsd4.8 Bash Version: 3.1 Patch Level: 11 Release Status: release Description: I've noticed that if I use ',' to repeat a substitution in vi-mode, bash either dumps core or goes into a hard loop. Repeat-By: Any command should do, I used this now as I was filling out this form: $ set -o vi $ date; date; date Fri Mar 3 12:53:06 CST 2006 Fri Mar 3 12:53:06 CST 2006 Fri Mar 3 12:53:07 CST 2006 Now, with vi-mode in effect, type 'ESC -' to bring up the "date..." command, type 'f e' to move the cursor to the first 'e', type 'r e' to replace the 'e' with 'e', type ';' to move the cursor to the second 'e', type '.' to repeat the previous substitution. For me, bash goes into a hard loop at this point and I need to 'kill -9' the process. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Tab completion breaks for tilde-paths with filenames containing space
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 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux bb 3.2.60dr #1 SMP Fri Oct 3 14:41:46 EDT 2014 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 37 Release Status: release Description: Pathnames starting with tilde, combined with filenames containing space, only partially tab-complete. Repeat-By: $ cd $ mkdir a $ touch a/a\ a.txt a/a\ a.odt $ vi a/a [correctly completes to] $ vi a/a\ a. a a.ods a a.txt ^C $ vi ~/a/a [correctly completes to] $ vi ~/a/a\ a. [further tabs do nothing] $ vi ~/a/a\ a.t[still nothing]
eval a=b\ c
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/bash/4.3.39/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash-4.3
-I../bash-4.3/include -I../bash-4.3/lib -g -O2
uname output: Linux s6.millcomputing.com 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed
Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 39
Release Status: release
Description:
# Echo the arguments, then execute them as a command.
function echodo() {
if [[ -n $ZSH_VERSION ]] ; then
echo "[ ${(q)@} ]"
eval${(q)@}
else
echo "[ $@ ]"
eval$@
fi
}
echodo echo b\ c
echodo a=b\ c
echo $a
The result in zsh is:
$ echodo echo b\ c
[ echo b\ c ]
b c
$ echodo a=b\ c
[ a=b\ c ]
$ echo $a
b c
$
Bash gets an error:
$ echodo echo b\ c
[ echo b c ]
b c
$ echodo a=b\ c
[ a=b c ]
bash: c: command not found
$ echo $a
$
I can't find a way to implement echodo in bash. Apparently this is because bash
is unable to expand a variable with quoting intact, as zsh can do with its (q)
expansion flag.
Bash behaves differently in this case::
$ echodo export a=b\ c
[ export a=b c ]
$ echo $a
b
$
Repeat-By:
Fix:
BASH_XTRACEFD=1 read variable stdout flushing?
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sulfur 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: I have `set -x` and `BASH_XTRACEFD=1` set in a simple script that I have in a cron job. I'd like to see the progress of the script when run manually, hence `set -x`, but I want the output to go to stdout rather than stderr so that cron emails me only when there is an actual failure. With this configuration, the `read` command is erroneously reading the "+" prompt output from `set -x` into the variable. It seems like stdout is not getting flushed propertly. Repeat-By: The following script attempts to read the first column of data, line by line, into a variable called `$var`. With `BASH_XTRACEFD` unset, it propertly prints r1c1, r2c1, r3c1, r4c1. With `BASH_XTRACEFD=1`, `$var` gets set to +, ++, r2c1, r3c1, r4c1. Maybe I am just being dumb? ``` #!/usr/bin/env bash BASH_XTRACEFD=1 set -x data=$(cat << END r1c1r1c2r1c3\n r2c1r2c2r2c3\n r3c1r3c2r3c3\n r4c1r4c2r4c3 END ) echo -e $data | while read -r var junk; do echo "var = $var" done ``` Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
Re: BASH_XTRACEFD=1 read variable stdout flushing?
Thanks for the explanation and the help! On Mon, Jan 16, 2023 at 1:53 PM Chet Ramey wrote: > On 1/16/23 12:36 PM, dave.dram...@gmail.com wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto > -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security > -Wall > > uname output: Linux sulfur 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 > 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > > Machine Type: x86_64-pc-linux-gnu > > > > Bash Version: 5.1 > > Patch Level: 16 > > Release Status: release > > > > Description: > > > > I have `set -x` and `BASH_XTRACEFD=1` set in a simple script that > I have in > > a cron job. I'd like to see the progress of the script when run > manually, > > hence `set -x`, but I want the output to go to stdout rather than > stderr so > > that cron emails me only when there is an actual failure. With this > > configuration, the `read` command is erroneously reading the "+" > prompt > > output from `set -x` into the variable. It seems like stdout is > not getting > > flushed propertly. > > > > Repeat-By: > > The following script attempts to read the first column of data, > line by > > line, into a variable called `$var`. With `BASH_XTRACEFD` unset, it > > propertly prints r1c1, r2c1, r3c1, r4c1. With `BASH_XTRACEFD=1`, > `$var` > > gets set to +, ++, r2c1, r3c1, r4c1. Maybe I am just being dumb? > > > > ``` > > #!/usr/bin/env bash > > > > BASH_XTRACEFD=1 > > set -x > > > > data=$(cat << END > > r1c1r1c2r1c3\n > > r2c1r2c2r2c3\n > > r3c1r3c2r3c3\n > > r4c1r4c2r4c3 > > END > > ) > > > > echo -e $data | while read -r var junk; do > > echo "var = $var" > > done > > ``` > > As you discovered, BASH_XTRACEFD makes the xtrace output write to the > designated file descriptor. If you write to fd 1, you're going to write the > trace output into the pipe, where `read' will see it. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Behavior of calling return from a trap
Hi all,
I'm noticing some odd behavior in an ERR trap with errtrace. It's
present in bash 3.2 and as well as 4.2. The simplest reproduction is
as follows:
--8<--
#!/bin/bash
somefunc() {
false
echo "shouldn't see this"
}
set -E
trap -- 'return 1' ERR
somefunc
echo "should see this"
--8<--
Both versions of bash throw an error, though fwiw the line number
differs: bash4 blames the line of where the trap is fired versus bash3
which blames the line where the trap is declared. The entire output of
the script is:
foo: line 4: return: can only `return' from a function or sourced
script
should see this
So, both versions give the intended behavior of returning from the
function despite the error. imo, there's a bug here somewhere, I'm
just not sure if it's the faulty error being thrown or if I shouldn't
be expecting the trap to work as it is when it's declared outside of a
function.
Regards,
Dave
Re: Behavior of calling return from a trap
On Tue, Apr 10, 2012 at 12:04:36PM -0400, Chet Ramey wrote: > You're calling the error trap twice. The first time you call it is after > the `false' in the body of the function, and the `return' works as intended > there. Since you return 1, the call to `somefunc' fails, triggering the > error trap again. The second time you call it, you're not executing in a > function context, and `return' throws an error. Ah, of course. That makes a lot of sense. Thanks for clarifying. dave
Re: [PATCH] Adding support for '--' in builtin echo's option parsing.
On Mon, Apr 01, 2013 at 03:16:07PM +0300, Hemmo Nieminen wrote: > > Description: > > Currently it seems to be impossible to e.g. print "-n" with the > > builtin > > echo witout any extra characters. > > You should use printf instead. The echo command is a historical artifact > which cannot be used for general-purpose output. > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html says: > > The echo utility shall not recognize the "--" argument in the manner > specified by Guideline 10 of XBD Utility Syntax Guidelines ; "--" > shall be recognized as a string operand. Perhaps this is worth adjusting unless POSIXLY_CORRECT?
Re: corrupted input after size function (input that's not recorded by bash)
Linda Walsh wrote:
>
> I have a small function in my bashrc:
>
> function showsize () {\
> local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
> echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
> }
> export -f showsize
> trap showsize SIGWINCH
> ---
> That has the effect of showing me my current window size
> when I resize it.
>
> The odd thing is, if I use it while at a bash input prompt --
> any command I type has the first word ignored.
Ignored or executed as a separate command?
Using bash 4.2.45, "echo ls /" is treated as "echo ; ls /" although
as you've noticed the command appears in the history as-typed.
>
> so if I type:
>> echo cmd
>
> If 'cmd' is not a typo you can use command-not-found to lookup the
> package that contains it, like this:
> cnf cmd
> ---
> But then I re-edit the line (in vi-mode, ESC-k, it shows me I typed
> echo cmd -- and, indeed, if I hit return, it echo's the word 'cmd'
> w/no error.
>
> So how can my showsize function be mangling the input in a way that
> prevents proper execution, but isn't recorded by bash?
Trial and error suggests it's something to do with new-style command
substitution. Try backticks:
local s=`stty size`
>
> (this has been one of those things that's bothered me for years, but
> never been important enough to even ask about... I thought I'd look at it
> to fix it, but still don't see why it does what it does).
>
> Any clues?
showsize()
{
local o="(${LINES}x${COLUMNS})" ; local s="${o//?/\\b}" ; printf "$o$s"
}
Re: How to test if a link exists
Mark Young wrote: > Hi, > > I stumbled into discovering that the -e test for a file does not > report the file as existing if the file is a dead symbolic link. It's documented in the bash manpage under "CONDITIONAL EXPRESSIONS". Unless otherwise specified, primaries that operate on files follow sym- bolic links and operate on the target of the link, rather than the link itself. > What test should I use to decide if a file exists (including dead > symbolic links)? -h and -L apply to the symlink rather than the target, so test -e broken_link -o -h broken_link
Re: How to test if a link exists
Mark Young wrote: > A little off topic but are -a and -e identical? As file existence tests, yes. -a also serves as logical "and".
RFE: a way to echo the arguments with quoting
I have an ugly function I wrote for zsh that does this:
Sat 14:17:25 ip2 yost /Users/yost
1 634 Z% echo-quoted xyz \$foo 'a b c ' '\n'
xyz '$foo' 'a b c ' '\n'
Sat 14:17:53 ip2 yost /Users/yost
0 635 Z%
It would be nice if there were an easy way to do this in bash.
Here is my use case:
echo-command() {
echo-n 1>&2 "[ "
echo-quoted -n 1>&2$@
echo 1>&2 " ]"
}
echodo() {
echo-command $@
eval "$@"
}
1 652 Z% echodo sleep 1
[ sleep 1 ]
0 653 Z%
This is a bit of a hack because when I need to use a pipe character, for
example, I have to quote it, and that gets echoed in a way that’s wrong for
this purpose.
0 656 Z% echodo echo abc \| sed 's,b,_,'
[ echo abc '|' sed s,b,_, ]
a_c
0 657 Z%
A builtin that does my ‘echodo’ without having to escape command-line
metacharacters is what I really want.
Is there such a thing?
typo in bash manual
In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
Where you say
ls *.gz | parallel -j+0 "zcat {} | bzip2 >{.}.bz2 && rm {}"
This will recompress all files in the current directory with names ending in
.gz using bzip2, running one job per CPU (-j+0) in parallel.
it should be
ls *.gz | parallel -j+0 "zcat {} | bzip2 >{.}.bz2 && rm {}"
This will recompress all files in the current directory with names ending in
.bz2 using bzip2, running one job per CPU (-j+0) in parallel.
Also, you should mention what the +0 does.
Re: When a hashed pathname is deleted, search PATH
On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey wrote: > On 3/15/14 2:44 PM, Reuben Thomas wrote: >> On 15 March 2014 18:23, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote: >> Is there a downside to making checkhash the default? > > Only the minor performance hit it would extract on every command lookup. Only on commands that were found in the hash table, correct? This is not a minor performance hit, but a trivial one. Consider this my vote for checkhash as the default. Dave
Re: bash-4.3 bug report
On Mon, Apr 14, 2014 at 12:22 PM, David Binderman wrote: > Anyone experienced looking at the code will always need to examine it > more closely to find out why it's a good idea in this case to use an array > index and *then* sanity check it's value. But in this case it's a limiting check, not a bounds check, and having it second helps to make this clear. I agree that the bug lies in the static analyzer.
Re: test for "command not found" before expanding shell parameters
This might suffice for the initial situation, as long as the expansion is
passed in with single quotes:
function check_n_run() {
greo="$1"; wild="$2"
if $(which "$greo" > /dev/null); then
$greo $wild;
fi
}
This is too cute to be useful, but it was enjoyable seeing the unintended
consequences when replace other, more used commands.
function greo() {
wild="$@"
if $(which "${FUNCNAME[0]}" > /dev/null); then
$(which "${FUNCNAME[0]}") $wild
fi
}
Dave Finlay
On Tue, Apr 22, 2014 at 1:03 PM, Chet Ramey wrote:
> > On Mon, Apr 21, 2014 at 3:16 AM, Andreas Schwab
> wrote:
> > > And if $greo is null the condition will also be true.
> >
> > Really? I'll be damned. That explains this problem
> > I've been having.
>
> Yes. `test' operates based on the number of arguments it receives. If you
> don't quote `$greo' and it expands to nothing, test receives a single
> argument (-n), tests it for nullness, and returns success.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
>
Re: PATH and $0
On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
In some Linux, it will print "/tmp/script.sh", while in other, it will
print "script.sh" only. Which is wrong? If both are fine, is there any
better way to make it portable?
Which do you want? (Both are fine.) If you want 'script.sh',
use 'basename' or the Bash equivalent, which I think is '${0##*/}'.
The canonical path would be a bit trickier.
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: PATH and $0
On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote: I want its full pathname using 'dirname', but it will give me unexpected result on some Linux or Bash versions. Well, 'dirname' certainly won't do what you want, but I'm sorry, I can't think of a way to get what you need. (It would be relatively easy in 'c'.) Even /proc/self/* doesn't contain the script's full pathname. Perhaps somebody else knows a better way. Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: null command and parameter expansion for "Display error if null or unset"
On 7/31/06, Poor Yorick <[EMAIL PROTECTED]> wrote:
The following line does not perform the "echo" command.
: ${FAKEVAR?} || echo hello
This seems inconsistent, since the return status is set to one, not to mention
that the null command is documented to return a zero exit code. It would be a
convenient and concise syntax for acting on unset variables.
Try this and then run your script:
export FAKEVAR="echo This could have been rm -rf $HOME"
to see why not to do it this way.
On the other hand, if you already know FAKEVAR is not set,
why are you performing a test?
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: null command and parameter expansion for "Display error if null or unset"
On 7/31/06, Paul Jarc <[EMAIL PROTECTED]> wrote:
"Dave Rutherford" <[EMAIL PROTECTED]> wrote:
> On 7/31/06, Poor Yorick <[EMAIL PROTECTED]> wrote:
>> : ${FAKEVAR?} || echo hello
>
> Try this and then run your script:
>
> export FAKEVAR="echo This could have been rm -rf $HOME"
That won't do anything. The contents of $FAKEVAR, if any, are just
passed as arguments to :, which does nothing.
Oh, yes; you're quite right. I couldn't see the colon in this font
and thought he was evaluating a possibly nonempty variable
as a command, which is apparently a bad idea that no-one had.
Sorry.
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
On 10/10/06, mwoehlke <[EMAIL PROTECTED]> wrote:
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash?
Well, I don't know if it's clever, but how about:
$ if [ "${SHELL//*/bash}" = "bash" ]; then echo y; fi
But better to use the hash-bang and make SURE the shell is Bash.
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to detect bash?
On 10/10/06, mwoehlke <[EMAIL PROTECTED]> wrote: Completely non-workable. That only works if the bash I want is in /bin/bash Well, no. It works as long as the last thing in the path is 'bash'. It could be /usr/bin/bash, /home/bin/bash, or yes, /bin/bash. But why the heck don't you know, if these systems are under your control? And why the heck do you think this is is *bug* in *bash*? Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Evaluate expression every time directory changes
On 6/28/07, bash_user <[EMAIL PROTECTED]> wrote:
Lets say I would like to update environment variable based on ${PWD}
should I clobber my prompt generation routine or there is a better way.
Something like this?
PROMPT_COMMAND='eval NEWPWD="\$PWD"'
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Subnet address
On 7/21/07, Archimerged Ark Submedes <[EMAIL PROTECTED]> wrote:
On 7/20/07, Mike Frysinger <[EMAIL PROTECTED]> did not read the question.
Neither did you. ;-) Asked for was a solution using ifconfig and bash;
you added grep and tr. Yes, that's entirely reasonable on your part,
but it's not necessary.
The answer is:
/sbin/ifconfig eth0 |
grep 'inet addr' | tr .: ' ' |
(read inet addr a b c d Bcast e f g h Mask i j k l;
echo $(($a & $i)).$(($b & $j )).$(( $c & $k )).$(( $d & $l )) )
Here's an ugly way to do it:
NETADDR=`/sbin/ifconfig |
while read w d z z; do
if [ "$w" = "inet" ]; then
d=${d#addr:}; z=${z#Mask:};
a=${d%%.*}; w=${z%%.*}; d=${d#*.}; z=${z#*.};
b=${d%%.*}; x=${z%%.*}; d=${d#*.}; z=${z#*.};
c=${d%%.*}; y=${z%%.*}; d=${d#*.}; z=${z#*.};
echo $((a&w)).$((b&x)).$((c&y)).$((d&z));
break;
fi;
done`
And here's a better way, inspired by your use of 'tr':
NETADDR=`/sbin/ifconfig |
while read w x y y; do
if [ "$w" = "inet" ]; then
set -- ${x//./ }; a=${1#addr:}; b=$2; c=$3; d=$4;
set -- ${y//./ }; w=${1#Mask:}; x=$2; y=$3; z=$4;
echo $((a&w)).$((b&x)).$((c&y)).$((d&z));
break;
fi;
done`
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: question and/or enhancement request
On 7/29/07, Erick Wodarz <[EMAIL PROTECTED]> wrote:
> I think the following is hard (or impossible?) using bash. I want to
> create a shell script that will ...
This may be possible, depending on exactly what you need,
but you'd probably be better off trying `expect'.
#!/bin/bash
mknod pipe_to_bash p
mknod pipe_to_prog p
# 1. Execute a program asynchronously, and return it's PID.
# awk program to multiply by 2, output in bash commands
awk '{ print "echo", 2 * $1 ";"}' < pipe_to_prog > pipe_to_bash &
childpid=$!
echo awk is $childpid, this bash is $$
# 2. Have the program read stdin from the shell's current stdout
# (if you write instead
# exec 9>&1 < pipe_to_bash > pipe_to_prog,
# both programs will block)
exec 9>&1 > pipe_to_prog < pipe_to_bash
# give awk some input
echo 5
echo 6
echo 7
exec >&9# closes pipe_to_prog (reconnecting original stdout)
# to trigger awk to read input
# 3. Have the program read write stdout to the shell's current stdin
# (You meant not to say "read", right?)
# read the commands output by awk from stdin
eval `while read w; do echo "$w"; done`
# (". -" would be better here... if it worked.
# Also tried ". /dev/stdin" without luck.)
rm pipe_to_bash pipe_to_prog
# Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: reading whitespaces and beginning and end of line
On Dec 7, 2007 5:49 AM, sancho1980 <[EMAIL PROTECTED]> wrote: > i have a script that reads lines from a file in this manner: > > cat infile | while read line > do > echo "$line" >> outfile > done > > The problem I have occurs whenever there is a whitespace at the end of a > line in the input file, because this whitespace get automatically truncated > from "$line", and i dont want that..i want the whole line to go into > outfile, no matter if the last characters are whitespace! You do win the coveted "useless use of cat" award, but even with that I can't reproduce your problem here. What version of bash are you using? $ cat -t -E test1 this $ file $ contains some $ extra^I$ whitespace $ $ while read; do echo "$REPLY" >> test2; done < test1 $ cat test1 | while read; do echo "$REPLY" >> test3; done $ l test* -rw-r- 1 dave dave 51 Dec 7 11:19 test1 -rw-r- 1 dave dave 51 Dec 7 11:19 test2 -rw-r- 1 dave dave 51 Dec 7 11:19 test3
Re: Comparison failure
On Jan 10, 2008 8:13 AM, Frans de Boer <[EMAIL PROTECTED]> wrote: > Following is a function which fails constantly. [...] > if [[ $i != -1 && $i < $((iPriTblCnt-1)) ]]; then > echo $((i+1)); > else > echo -1 > fi Now, "[[" isn't very well documented, so I tend not to use it, but notice how "<" behaves here. It looks like it's doing a string comparison. Try "-lt" to get a numeric less-than. > -- Example trace 1 -> [...] > ++ [[ 5 < 54 ]] > ++ echo 6 [...] > ++ [[ 6 < 54 ]] > ++ echo -1 [...] > - Example trace 2 -> [...] > ++ [[ 1 < 109 ]] > ++ echo 2 [...] > ++ [[ 2 < 109 ]] > ++ echo -1 Regards, Dave
Re: Comparison failure
Chet Ramey wrote:
> Dave Rutherford wrote:
> > Now, "[[" isn't very well documented, so I tend not to use it,
>
> I'm always interested in suggestions for improving the bash documentation.
> Can you tell me what's unclear about the existing description of
> `[['?
It's probably my fault. I just don't really understand why it exists.
I know it does one thing -- =~ -- that `test' doesn't. I've never
needed that. The string operators ${#, %, /} are my friends.
So are awk and sed. And bash in general, for that matter.
But if I need a regex, it's probably to do some modification,
so I'll need to do more with it than merely match it.
If `test' weren't a shell builtin but was still /bin/[, I'd be using
[[ for speed. But it is, so I don't.
I know test's quirks. Does [[ have quirks? Are they the same?
Is there room in my grey matter to hold both sets of quirks
and keep them straight?
Perhaps a FAQ entry, or a part of the man page, explaining
when to use [[ and when [ would be of some help.
Best regards,
Dave
Re: converting an array into a single variable
On Wed, Feb 20, 2008 at 2:42 PM, Natan Shar <[EMAIL PROTECTED]> wrote:
> I can do this with a few id numbers using php, but I need to do this with
> thousands of id numbers on a daily basis using a cron job
>
> I can successully build an array of the filenames using:
> declare -a imagelist='ls www/images/124534_*.JPG';
>
> But then I am stuck with the problem of srtipping the 'www/images/' off of
> each array element. I am trying:
> for file in [EMAIL PROTECTED]
> do
> declare newfile=echo $file | sed 's/www\/images\///g'
> echo $newfile
> done;
More complicated than it needs to be.
ITEM=124534
imagelist=`cd www/images; echo $ITEM_*.JPG`
if [ "$imagelist" = "$ITEM_*.JPG" ]; then imagelist=""; fi
imagelist="${imagelist// /,}"
Nothing but builtins.
Dave
Re: for ... in ... do ignores escape characters
On Thu, Apr 17, 2008 at 4:21 PM, luiscolorado <[EMAIL PROTECTED]> wrote:
> Hello, everybody... I'm suffering a huge problem with the "for" command
> because it wants to parse a variable ignoring escape characters.
>
> For example, as you know, if I do something like this in bash:
>
> for i in sony apple "hewlett packard"
> do
> echo $i
> done
>
> It will echo the following:
>
> sony
> apple
> hewlett packard
>
> However, I have a program that generates a list of files (let's say like the
> previous one) that I want to use. This is what I get when some file names
> have spaces:
>
> for i in `my-program`
> do
> echo $i
> done
>
> It echoes the following:
>
> sony
> apple
> hewlett
> packard
>
>
> Did you notice how it broke "hewlett packard" in two separate strings? That
> is, it uses the spaces to parse the file names!
Quotes or escapes in the output of the `` are input to the shell rather
than shell syntax, so won't be interpreted. You just need to quote more.
$ foo () { echo sony; echo apple; echo hewlett packard; }
Now note the difference between:
$ for w in "`foo`"; do echo $w; done
sony apple hewlett packard
and
$ for w in `foo`; do echo "$w"; done
sony
apple
hewlett
packard
and
$ for w in "`foo`"; do echo "$w"; done
sony
apple
hewlett packard
Why the first one does that I'm not sure, but it's the last one you want.
Dave
Re: at which byte do two strings differ
On Tuesday 6 May 2008 07:53, Nathan Coulter wrote: > Looking for a simple ways to output the byte at which two strings differ. > Here is one: > > cmp <(echo "hello") <(echo "help") | cut -d' ' -f5 | tr -d , > > Any other suggestions? I can't see how this pertains to gnu.bash.bug, however try this: echo 'hello help' | sed 's/\([^ ]*\)[^ ]* \1.*/\1/' | wc -m (this exploits the fact that a newline is appended at the end, so wc sees an additional character, and gives the expected result). If the strings can have spaces in them, then use a different separator. -- D.
Re: finding the index at which two strings differ
On Tuesday 6 May 2008 21:29, Bob Proulx wrote:
> I can't think of any way to do this natively in bash
Well, there's a loop solution, but it's a bit awkward:
a=help; b=hello; i=0
while [ $i -le $((${#a}-1)) ] && [ $i -le $((${#b}-1)) ]; do
if [ "${a:${i}:1}" = "${b:${i}:1}" ]; then
i=$((i+1))
else
break
fi
done
echo $((i+1))
--
D.
Re: finding the index at which two strings differ
On Tuesday 6 May 2008 22:33, Dave B wrote:
> while [ $i -le $((${#a}-1)) ] && [ $i -le $((${#b}-1)) ]; do
while [ $i -lt ${#a} ] && [ $i -lt ${#b} ]; do
--
D.
Re: Bash messes up spaces in command line agruments.
On Tuesday 6 May 2008 16:20, Herrmann, Justin wrote:
> Description: When I try to pass strings inside double or single quotes
> as command line arguments to my Bash script, leading spaces, trailing
> spaces, and multiple grouped embedded spaces are removed from the
> string. This also prevents me from passing in only a space or spaces as
> arguments to my script.
>
> Repeat-By: Save this script as 'startup':
>
> #!/bin/bash
> echo $#
> for ((index = 0; index <= $#; index++))
> do
> echo "$index |$(eval echo \${$index})|"
> done
> exit 0
>
> then type: ./startup ' some words '
>
> the script will print out:
> 1
> 0 |./startup|
> 1 |some words|
This is what I get:
$ ./startup ' some words '
1
0 |./startup|
1 | some words |
# ' some words '
Note that a space is missing. Try using the simpler indirection notation:
$ cat startup
#!/bin/bash
echo $#
for ((index = 0; index <= $#; index++)); do
echo "$index |${!index}|"# Try using this
echo "$index |$(eval echo \${$index})|"
done
exit 0
$ ./startup ' some words '
1
0 |./startup|
0 |./startup|
1 |some words |
1 | some words |
# ' some words '
I'm not sure about why, using your method, only a single space is lost
(instead of all leading, trailing and all but one intra-words).
I'm using
$ bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
--
D.
Re: Bash messes up spaces in command line agruments.
On Wednesday 7 May 2008 14:54, Dave B wrote:
> $ ./startup ' some words '
> 1
> 0 |./startup|
> 0 |./startup|
> 1 |some words |
> 1 | some words |
> # ' some words '
This should have been
$ ./startup ' some words '
1
0 |./startup|
0 |./startup|
1 | some words |
1 |some words |
# ' some words '
ie, ${!index} works fine, while eval loses a space.
--
D.
Re: unexpected behavior of 'read' builtin
On Saturday 24 May 2008 02:44, Juliano F. Ravasi wrote: > Description: > > I got bitten by two unexpected (and undocumented) behaviors of > the 'read' builtin. > > The first one is that it doesn't seem to handle word separators > equally, making distinction when spaces and non-space > separators are used to separate words. The man page introduces the concept of "IFS whitespace", which seems to include space and tab characters. "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). Any character in IFS that is not IFS whitespace, along with any adjacent IFS whitespace characters, delimits a field. A sequence of IFS whitespace characters is also treated as a delimiter." So, if I read that correctly (which might not be true of course), when you assign $'\t' (an IFS whitespace character) to IFS, it seems you fall into the case where "a sequence of IFS whitespace characters is also treated as a delimiter". > The second one is that it chops leading and trailing whitespace > when you provide one variable for assignment, and not when you > use the default $REPLY. This /seems/ to be documented. From the man page, section about "read": "If no names are supplied, the line read is assigned to the variable REPLY". So, I guess "the line read" here really means "the whole line", including leading/trailing spaces. On the other hand, when even a single name is supplied, word splitting is performed, so the removal of blanks is expected as the result of that. -- D.
Missing .bash_history Entries
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='l$ uname output: Linux jaguar 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 200$ Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: It is possible to execute commands from the command-line without them appearing in the .bash_history file. This is a slight nuisance as any command that is accidentally preceded with a space will not appear when cycling through commands using the arrow keys. Repeat-By: Precede the command to execute with a single space. Fix: Don't type in a space by accident. ;-)
Re: [[ ... =~ ... ]] is broken when RHS is quoted
Alexis Huxley wrote: > Description: > [[ ... =~ ... ]] is broken when RHS is quoted AFAICT that seems to have changed from 3.2alpha. According to the changelog, from version 3.2alpha, "Quoting the string argument to the [[ command's =~ operator now forces string matching, as with the other pattern-matching operators". $ bash -c '[[ "^apple" =~ ^apple ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='()' $ bash -c '[[ "^apple" =~ "^apple" ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="^apple")' Spaces (and possibly other special chars) in the RHS should be escaped: $ bash -c '[[ "apple banana" =~ ^apple\ banana ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="apple banana")' $ bash -c '[[ "apple banana" =~ ^(apple)\ (banana) ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="apple banana" [1]="apple" [2]="banana")' $ bash --version GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. -- D.
Re: [[ ... =~ ... ]] is broken when RHS is quoted
Alexis Huxley wrote:
> "Quote removal" means that, as usual, quotes do not form part of the
> arguments, they merely serve to delimit the arguments, I take it.
> "Words between [[ and ]] ... quote removal performed" means on *all*
> words between [[ and ]] I take it. Hmm ... No, that can't be right
> otherwise
>
> bash -c '[[ "apple" =~ "(apple)" ]]; echo ${BASH_REMATCH[1]}'
>
> would say apple. Hmmm ... while the CHANGES file indicates that I
> was wrong that bash is broken, I would say that bash is broken
> *w.r.t. the behaviour documented in its man page*. What do you think?
But bash *does* do quote removal, if you supply quoted arguments. If you do
bash -c '[[ "apple" =~ "(apple)" ]]; echo ${BASH_REMATCH[1]}'
then bash does quote removal and sees
apple =~ (apple)
Then, since the RHS was quoted, it performs string matching instead of re
matching. But before that it did do quote removal nonetheless.
--
D.
Re: Strange return codes of continue
Roman Rakus wrote: > This is realy strange. I have two examples > First: > > while [ 1 ]; do > while [ 1 ]; do > continue 0 > done > done > echo $? > > > Second: > > while [ 1 ]; do > while [ 1 ]; do > continue 0 > done > echo $? > done > echo $? > > In first case I have echoed 1. And I am expecting the same result in > second case, but I get 0. Can anyone help me and say where is the > difference? continue [n] Resume the next iteration of the enclosing for, while, until, or select loop. If n is specified, resume at the nth enclosing loop. n must be >= 1. If n is greater than the number of enclosing loops, the last enclosing loop (the ‘‘top-level’’ loop) is resumed. The return value is 0 unless the shell is not executing a loop when continue is executed. -- D.
Re: Regular expression match operation with character classes fails in bash 3.2
John E. Wulff wrote: > I have just updated from "openSUSE 10.2" to openSUSE 11.0" Linux. My > backup shell script > is now broken. I tracked the problen down to the latest version of > "bash". > > The relatively new binary operator =~ does not match a regular > expression which contains a > character class in square brackets: eg. $xp =~ "[0-9]10" > > The behaviour is the same on a 32 bit machine with openSUSE 11.0 and > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) > > All three script lines below match correctly on SuSE Linux 9.3 with > GNU bash, version 3.00.16(1)-release (i586-suse-linux) > > Unfortunately I no longer have access to the bash version which worked > correctly with openSUSE 10.2 > > My observation is the fault was introduced fairly recently. > > Repeat-By: > The following very simple regular expression matches: > xp=310; if [[ $xp =~ "310" ]]; then echo "$xp matched"; else echo "$xp > not matched"; fi > > This does not match in Bash Version 3.2 > xp=310; if [[ $xp =~ "[0-9]10" ]]; then echo "$xp matched"; else echo > "$xp not matched"; fi > > This does not match either (more like the line in my broken shell > script) > xp=310; if [[ $xp =~ "[0-9][0-9]*" ]]; then echo "$xp matched"; else > echo "$xp not matched"; fi That has been discussed some days ago, it's the expected behavior. See http://lists.gnu.org/archive/html/bug-bash/2008-06/msg00083.html -- D.
Re: How to create parameterized aliases in bashrc
Aman Jain wrote:
> Hi
>
> I would like to create an alias to show Nth line of a file.
>
> I tried something like
> alias shline='head -$1 $2 | tail -1' #$1 is the line number and $2
> is the filename
># Usage should be :
> $shline 5 file.txt
>
> But it isn't working..
You can't pass parameters to aliases.
> Can anyone suggest a better alternative
Use a function.
shline() { head -n $1 "$2" | tail -n 1; }
--
D.
Re: 'read' primitive
Bob Proulx wrote: > To get the entire line verbatim you would need to use the $REPLY > variable. Or also use IFS= read -r foo < bar -- D.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston wrote:
>> > On Tue, Aug 26, 2008 at 5:41 AM, R. Bernstein <[EMAIL PROTECTED]> wrote:
>> > > Both zsh and ksh have a way to open a file or duplicate a file
>> > > descriptor and let the interpreter pick the descriptor saving the
>> > > newly-allocated file descriptor number in a variable. In particular:
>> > >
>> > > exec {fd}<&0
>> Perhaps you are thinking of the variation without braces?
>>
>
> well, I was thinking of the normal redirection syntax:
> exec 3<&0
>
> I doubt '{fd}<&0' is meaningfull anywhere.in ksh {fd} tries to
> run the command {fd} like in bash
> in zsh it tries to run the command "fd"
> What are you talking about???
I think he refers to the fact that, with ksh, you can do for instance
$ exec {fd}<&0
$ echo $fd
10
$ exec {fd1}<&0
$ echo $fd1
11
I didn't try on zsh, but with bash you get:
$ exec {fd}<&0
-bash: exec: {fd}: not found
--
D.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston wrote:
>> I think he refers to the fact that, with ksh, you can do for instance
>>
>> $ exec {fd}<&0
>> $ echo $fd
>> 10
>> $ exec {fd1}<&0
>> $ echo $fd1
>> 11
>>
>> I didn't try on zsh, but with bash you get:
>>
>> $ exec {fd}<&0
>> -bash: exec: {fd}: not found
>>
> ah sorry I didn't know this syntax
>
> on which ksh version does this work?
I tried that on a RHEL 5 system with
$ ksh --version
version sh (AT&T Labs Research) 1993-12-28 r
Actually, I just tried zsh, and the version installed on that system (which
looks pretty old) does not support the exec {fd}<&0 either.
$ zsh --version
zsh 4.2.6 (i686-redhat-linux-gnu)
--
D.
Re: Maximum limit of pipes in a single command ?
Keshetti Mahesh wrote: > Hi all, > > Can anyone tell me what is the maximum limit of number of pipes > that can be opened through a single command ? > > e.g; # ||| .| For what is worth, on my system (bash 3.2.33(1)-release) I can have 3332 pipes before bash gives an error. I used this command: (printf 'echo a';for i in `seq 1 3332`;do printf '|cat';done;echo) | bash If I replace 3332 with , bash gives bash: line 1: syntax error near unexpected token `|' Curiously, with this command (printf 'echo a';for i in `seq 1 3330`;do printf '|(read a;echo $a)'; done;echo) | bash the limit is 3330. Ulimit tells me that the maximum number of user processes is 16381, so it seems unrelated to that. Why do you want to know? -- D.
Re: Formating variable with caracter and date.
Dolphin06 wrote: > Hello all, > > I would like to give a variable a value which have a format like this one: > <3 letters>-- > should be yymmdd. Date of the day by default. > How would i do this, i know the date command is date +"%y-%m-%d", but i dont > know the syntax for mixing letters date and digit into one variable. > Also i would like to give the user a chance to change this default value, by > letting him enter one, so i would like to know how can i check if the > entered value is in the correct format. First of all, this list if for reporting bash bugs, not for general help requests. For that purpose, there are other, more appropriate, places, like for example the Internet newsgroup comp.unix.shell. Then, regarding your request: To assign that string to the variable, assuming <3 letters> is "ABC", and is "5" (replace with your own values), you can do this: var=ABC-$(date +%y%m%d)-5 The part about checking depends on what you want to check exactly, which isn't clear from your description. -- D.
Re: $(grep anycommand anyfile) fail
BlackEnvil wrote: > Description: using ` ` or $() with command that use dirnames with spaces > fail. > > there are diferent dirnames with this problem, and different situations that > cause these errors, not only with ls and not only with grep. > > bye > > > Repeat-By: > > [blacken...@space_star ~]$ cd $HOME; mkdir hello\ -world/; touch test; echo > "ls hello\ -world/" > test; $(grep ls test); > ls: invalid line width: orld/ > [blacken...@space_star ~]$ There are actually two problems here. After the command substitution, the shell does word splitting, and the command it sees is this (spaced for readability): ls hello\ -world ^^ ^^ arg1 arg2 The -world part is interpreted as the option -w to ls, and "orld" as the argument to that option, which is an invalid line width. To fix that, use -- to mark the end of options. But even if you do that, you would still get an error because ls would see two filenames: "hello\" and "-world", neither of which exists. > [blacken...@space_star ~]$ cd $HOME; mkdir hello-\ world/; touch test; echo > "ls hello-\ world/" > test; $(grep ls test); > ls: cannot access hello-\: No such file or directory > world/: > [blacken...@space_star ~]$ Same as above: the shell does word splitting on the result of command substitution, and what it sees is the command (spaced for readability) ls hello-\ world ^^^ ^ arg1 arg2 since those files or directory do not exist, ls correctly produces an error. In both cases what you're seeing is not a bug, but just expected behavior. -- D.
Re: Howto set a Readline variable (not in the init file!)?
Andi Bachmann wrote: > Hello > > I'm looking for a way to set a Readline variable, but without editing > the init (~/.inputrc or /etc/inputrc) file. > > E.g., I'd like to have > >set show-all-if-ambiguous on > > The thing is that I have to login to some remote server with a login > that I share with other users and I don't want to impose my settings by > saving my options in a file. > > I tried > > bind set show-all-if-ambiguous on > > but this leads to a corrupted readline behaviour: I can't type anymore 's'. > > Reading the manual > (http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins) it > says explicitly (for the Builtin command 'bind'): > >"Display current Readline (see Command Line Editing) key and > function bindings, bind a key sequence to a Readline function or > macro, or set a Readline variable." According to the man, you should pass the readline binding or variable as a single argument to bind (or at least that's what the example shown seems to imply), so: bind 'set show-all-if-ambiguous on' The above line seems to do the trick for me. -- D.
Re: No tilde expansion right after a quotation
Angel Tsankov wrote:
> Eric Blake wrote:
>> According to Angel Tsankov on 2/15/2009 3:02 PM:
>>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>>> expansions just to be on the safe side, though I think home
>>> directories may not contain spaces.)
>> There are some contexts, such as variable assignments, where double
>> quotes are not necessary.
>>
>> foo='a b'
>> bar=$foo
>>
>> is just as safe as
>>
>> bar="$foo"
>>
>> In fact, it is MORE portable to avoid double quotes in assignments,
>> if you are worried about writing scripts portable to more than just
>> bash. Of these two constructs:
>>
>> foo="`echo "a b"`"
>> bar=`echo "a b"`
>>
>> only the setting of bar is guaranteed to parse correctly in all
>> shells.
> Eric, thanks for youy replay. If double quotes are not that portable, then
> how am I suppose to assign the output from some command to a variable when
> the output contains a space?
Word splitting doesn't happen on assignments, so:
$ var=$(echo "foo bar baz")
$ echo "$var"
foo bar baz
--
D.
Re: Creating directories with sticky bit set
On Fri, Mar 13, 2009 at 9:30 AM, Greg Wooledge wrote:
> This still doesn't address the original poster's concerns if, for
> example, a web browser creates a new ~/.browserconf directory the first
> time it's invoked. But nothing bash can do will solve that.
True, but what about a wrapper?
--- sticky.c
#include
#include
#include
int mkdir (const char *path, mode_t mode)
{
typedef int (*FP_mkdir)(const char *, mode_t);
FP_mkdir org_mkdir = dlsym(((void *) -1l), "mkdir");
return org_mkdir(path, mode | S_ISVTX);
}
--- building
$ gcc -fPIC -c -Wall sticky.c -o sticky.o
$ gcc -shared sticky.o -ldl -lstdc++ -o sticky.so
--- running
$ export LD_PRELOAD=$PWD/sticky.so:$LD_PRELOAD
--- for long-term use, add to bash startup files
How portable this is I don't know, but I tested it briefly and it
seems okay; YMMV.
Dave
Re: IFS valid characters
Stephane CHAZELAS wrote:
> 2009-03-10, 15:43(-04), Chet Ramey:
>>> What are the valid charactes for the IFS variable? In particular, is '\0' a
>>> valid one?
>> Technically, yes, but in practice it's not useful. There are too many things
>> represented as C strings to make NUL work right.
> [...]
>
> And to answer the rest of the question. In bash, any character
> except NUL is allowed in $IFS.
>
> Some points that should be noted:
> - the SPC, TAB and NL characters are treated specially.
> - contrary to in the Bourne shell, pdksh or zsh, IFS is an
> internal field terminator, not separator ("a:b:" is split
> into "a" and "b", not "a" and "b" and "" which makes it
> inappropriate to split $PATH for instance) (in the Bourne
> shell, it splits into "a" and "b" as well but that's because
> empty elements are removed there)
It looks like an empty word is created when the separator is at the
beginning, but not when it's at the end (bash 3.2 and 4):
$ IFS=':'
$ v=":a:b"
$ arr=($v)
$ declare -p arr
declare -a arr='([0]="" [1]="a" [2]="b")'
$ v="a:b:"
$ arr=($v)
$ declare -p arr
declare -a arr='([0]="a" [1]="b")'
--
D.
Re: $\n doesn't get expanded between double-quotes
On Friday 03 July 2009, Richard Neill wrote: > > X=$'a\nb c' > > This is still a missing feature: how to embed newlines in double-quoted > bash string assignment: > > For example, if I want to write: > > EMAIL_BODY="Dear $NAME,$'\n\n'Here are the log-files for > $(date)$'\n\n'Regards,$'\n\n'$SENDER" > > then this doesn't work. There are ways around it, such as: > - building up the string in pieces or > - EMAIL_BODY=$(echo -e "$EMAIL_BODY") > > but it's really ugly to do. Maybe I'm missing something, but what's wrong with EMAIL_BODY="Dear $NAME, Here are the log files etc." ? -- D.
Re: Possible Feature Requests (unsource, exchange)
On Tuesday 07 July 2009, Christopher Roy Bratusek wrote:
> Hi all,
>
> what I'm currently missing are the following two things (I'm not 100%
> sure if they are not available):
>
> unsource: the opposite of source (while source is making functions
> publically available, unsource would remove them)
source does not make any function available. It just reads and executes the
contents of the sourced file in the current context. If that file happens to
contain functions, those functions will be defined and available (not to
children though, unless they're exported), but it's just a side effect.
To "remove" a function, you just unset it:
$ foo() { echo "function foo"; }
$ foo
function foo
$ unset foo
$ foo
bash: foo: command not found
> exchange: exchanges the value of two variables (x=2 y=a; exchange x y;
> x=a y=2 -- need to be exported, so $1 $2 inside a function/script don't
> help that much)
The traditional way to exchange values between two variable is to use a
temporary variable:
$ x=a
$ y=2
$ tmp=$x
$ x=$y
$ y=$tmp
$ echo "now x is $x, y is $y"
now x is 2, y is a
It's not clear to me what you mean by "$1 $2 inside a function/script don't
help".
> echo no-expand: if you do echo $@ ($@ is $x $y for example) echo will
> print the values of $x $y instead of simply $x and $y is there a way to
> achieve this?
Sure, just quote it (and not only here, btw):
$ foo() { echo "$@"; }
$ foo '$x' '$y'
$x $y
--
D.
Re: regarding 'time' builtin
On Friday 17 July 2009, Linda Walsh wrote: > where does the output from the 'time' command "go" > > I.e. if I wanted to pipe the output to a prog or file, how would I > go about doing it? Please see http://mywiki.wooledge.org/BashFAQ/032 -- D.
Re: 'time' redirection, and pipe redirections in general
On Saturday 25 July 2009, Linda Walsh wrote: > AFAIK, I'm still screwed if I want to create more than one > pipe for outputs -- either sending stderr to one pipe and stdout to > another, OR a way of even doing what "tee" does, but built into the > shell, so I could, using the building "tee", a file descriptor as an > output target. IIUC, This can be accomplished with process substitution: myprogram 1> >(command1) 2> >(command2) 3> >(command3) etc.etc. where command1 gets what myprogram writes to fd 1, command2 gets what myprogram writes to fd 2, etc.etc. But maybe I'm not understanding correctly what you're looking for. -- D.
Re: Bash script file naming problem?
On Saturday 25 July 2009, michael rice wrote: > Is there a problem with naming a bash script file "script"? I'm using > Fedora 11. "script" is most likely the name of a command installed on your system (on mine, it's /usr/bin/script). Try "man script" and see. So if you really want to call your script "script", but you have to either call it using its path (./bin/script in your example), or make sure that the shell finds it before the system command for example by modifying PATH. To be honest, I would just pick a different name for your script. -- D.
Re: Bug in array populating does not respect quotes
On Thursday 24 September 2009 16:38:12 David Martin wrote:
> Description:
> When populating an array from a string in a variable does not
> handle quotes.
>
> Repeat-By:
>
> ~$ declare -a samplearray
> ~$ samplearray=( x y 'z k')
> ~$ echo ${samplearray[2]}
> z k
> ~$ samplestring="x y 'z k'"
> ~$ samplearray=( $samplestring )
> ~$ echo ${samplearray[2]}
> 'z
Not a bug. This is expected behavior. To do what you want, use eval:
~$ samplestring="x y 'z k'"
~$ eval samplearray=( "$samplestring" )
~$ echo "${samplearray[2]}"
z k
--
D.
Re: Real easy questions. Please answer
On Friday 25 September 2009 05:24:04 eatsubway wrote:
> sry i have a stupid question.
>
> I have a variable and need to know how many items are in it.
>
> for example:
> variable="abc xyz foo"
> what program can i call to print out 3
>
> right now im doing this...
>
> Counter()
> {
> echo $#
> }
> Counter $IDs
> but that just seems stupid
Use an array, so you will even be able to store elements with spaces in them.
--
D.
Re: bash accepts script with incorrect syntax and goes into infinite loop
On Friday 09 October 2009, Pierre Gaston wrote: > > Repeat-By: > >printf '%s\n%s\n' foo bar | while read NAME; > >echo NAME=$NAME > >do > >echo blah > >done > > Not sure what is the incorrect syntax, and it seems normal that it goes > into an infinite loop since echo is always true. Well, it seems to me (and as stated in the bug report) that a "do" should follow the "while read NAME;". -- D.
Re: bash accepts script with incorrect syntax and goes into infinite loop
On Friday 09 October 2009, Pierre Gaston wrote: > > Well, it seems to me (and as stated in the bug report) that a "do" should > > follow the "while read NAME;". > > the while syntax is like this: > "while list; do list; done" > and the manual says "A sequence of one or more newlines may appear in a > list instead of a semicolon to delimit commands." > so you can have: > > while command > command > do > > (the ; in the definition is probably there to keep the definition on one > line, you can replace the ; in all the other definitions by a newline like: > if command > then > > This also works the same way in the other shells. For me it's not a bug. Uhm, on a more accurate reading you're probably right. The POSIX syntax for while is while compound-list-1 do compound-list-2 done And "read NAME; echo NAME=$NAME" is a compound-list. So I was deceived by the formatting, I think you are right. Thanks for correcting me. -- D.
Re: how to start in "overwrite-mode"
On Tue, Oct 27, 2009 at 16:29, Jim Lawson wrote: > I have a user we're trying to encourage to migrate from tcsh to bash, > who is used to his shell starting up in overwrite mode (as opposed to > the default Insert mode.) > > Long story short, while I can easily bind a key to the "overwrite-mode" > readline function, I can't figure out how to make bind start up that way > as I can't find an "overwrite" readline variable which I can manipulate. > And the user doesn't want to hit "Ins" every time he starts a shell. > > Anyone know how to do this? With the caveats that this is an awful solution, and it requires that the user be willing to commit to one or two terminal types (say, Xterm), I found a horrible way to do this. The control characters below are literal in the real files. Assuming the insert key on your keyboard is ^[[2~ : Add to .Xdefaults: XTerm*answerbackString: ^[[2~ Add to .bashrc (and .profile if it doesn't source .bashrc): bind '"^[[2~": overwrite-mode' PROMPT_COMMAND='echo -n ^E' This causes xterm to respond by simulating a pressing of the insert key before each PS1 prompt, putting that line into overwrite. If the user drops down to a PS2, etc. prompt, that line will be in insert mode. I didn't solve that; putting a ^E into PS* didn't work for some reason. (Why?) Dave
undefined reference to `__strtoll'
Configuration Information [Automatically generated, do not change]: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='hppa2.0w' -DCONF_OSTYPE=' hpux11.00' -DCONF_MACHTYPE='hppa2.0w-hp-hpux11.00' -DCONF_VENDOR='hp' -DLOCALEDI R='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DHPUX -I . -I. -I./include -I./lib -g -O2 uname output: HP-UX halflife B.11.00 U 9000/785 2012264887 unlimited-user licens e Machine Type: hppa2.0w-hp-hpux11.00 Bash Version: 4.1 Patch Level: 0 Release Status: release Description: 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. 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 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 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 Any help appreciated, -dave
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 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 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 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 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 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: Failed bash -r command returns 0 exit status
On Mon, May 24, 2010 at 02:48, Pitt, David wrote: > However executing "/bin/ls && /bin/ls" under a restricted shell > returns a zero exit > status. This is not expected (at least not by me!). Zero exit > status is returned with > any list of commands, e.g. "/bin/ls && :". That one would, since the second command is 'true'. Replace it with 'false' and you should see an exit status of 1. As for "/bin/ls && /bin/ls", since neither command runs neither one fails, either. 'Tis a bit of a head-scratcher, though. Dave
Re: Failed bash -r command returns 0 exit status
On Mon, May 24, 2010 at 08:32, Greg Wooledge wrote: > On Mon, May 24, 2010 at 04:25:48AM -0400, Dave Rutherford wrote: >> On Mon, May 24, 2010 at 02:48, Pitt, David wrote: >> > status. This is not expected (at least not by me!). Zero exit >> > status is returned with >> > any list of commands, e.g. "/bin/ls && :". >> >> That one would, since the second command is 'true'. Replace it >> with 'false' and you should see an exit status of 1. > > You're confused. In a regular shell, the if the /bin/ls fails, the && > part never gets executed at all, and the entire thing returns non-zero. > > $ bash -c 'false && :'; echo $? > 1 But it didn't fail because it wasn't run.
Re: How to run something before invoking the inputted command?
On Mon, Jul 12, 2010 at 08:16, Greg Wooledge wrote:
>> On Sat, Jul 10, 2010 at 11:30 AM, Eric Blake wrote:
>> > Not quite before the command, but it is very easy to include $(date) as
>> > part of PS1 to have a timestamp listed in the prompt that is printed
>> > after every command.
>
> On Sat, Jul 10, 2010 at 11:54:05AM +0800, Clark J. Wang wrote:
>> Yes, timestamp in PS1 is fine for after-command purposes. And actually I use
>> the PROMPT_COMMAND var for that.
>
> unset PROMPT_COMMAND
> PS1='$(date +%H:%M:%S)|\h:\w\$ '
Why not just use the \t escape in PS1? Or, if you want other
arguments to strftime, you could write \D{%H:%M:%S}.
Re: bash feature request: pushd -v, popd -v
On 7/15/05, Ben Horowitz <[EMAIL PROTECTED]> wrote:
> I grew to appreciate one feature of tcsh: the ability to use
> the commands pushd -v, and popd -v.
>
> As you know, when the bash pushd and popd commands are successful,
> they print the directory stack. In tcsh, one can additionally issue
> the command pushd -v, which is like the bash commands pushd followed
> by dirs -v. This feature appears not to be available in bash.
>
> tcsh> pushd -v /tmp
> 0 /tmp
> 1 /
Does this do the trick?
pushd ()
{
local verbose=0;
if [ "$1" = "-v" ]; then
verbose=1;
shift;
fi;
builtin pushd "$@";
if [ $verbose -eq 1 ]; then
for w in [EMAIL PROTECTED];
do
echo "$w${DIRSTACK[$w]}";
done;
fi
}
Barely tested (and with bash 3.0 at that), but it seems to do
what you want. popd would be very similar, of course.
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bash problem with #!
Please see http://Yost.com/computers/compileAndGo That page describes a #!/bin/bash script called compileAndGo, which is used as the program for a #! script. In other words, a program starting with #!/usr/local/bin/compileAndGo should invoke /usr/local/bin/compileAndGo, and compileAndGo is a program starting with #!/bin/bash Invoking a compileAndGo script works correctly in zsh, but not in bash, sh, ksh, csh, or tcsh. (Is this the first time anyone has used a shell script as a #! program?) Thanks Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash problem with #!, rev 2
[added a diagnosis near the end.] Please see http://Yost.com/computers/compileAndGo That page describes a #!/bin/bash script called compileAndGo, which is used as the program for a #! script. In other words, a program starting with #!/usr/local/bin/compileAndGo should invoke /usr/local/bin/compileAndGo, and compileAndGo is a program starting with #!/bin/bash Invoking a compileAndGo script works correctly in zsh, but not in bash, sh, ksh, csh, or tcsh. The problem is that bash is executing the compileAndGo script as if it were a bash script. (Is this the first time anyone has used a shell script as a #! program?) Thanks Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash problem with #!, rev 2
Thanks for your learned analysis. 1. I kind of like the way zsh handles it. 2. In any case, I'll use #!/usr/bin/env http://Yost.com/computers/compileAndGo 3. I'll change my pages to reflect the change by around noon 15:00 UTC+8. Thanks again. Dave ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Cygwin bash build- command substitution fails
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4 -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib -DWORDEXP_OPTION -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3 -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3 -Wno-parentheses -Wno-format-security uname output: CYGWIN_NT-10.0 ddtlap 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin Machine Type: x86_64-unknown-cygwin Bash Version: 4.4 Patch Level: 12 Release Status: release Description: I'm trying to do a Cygwin build of the bash git repo at bminor/bash on github. The configure (no options) and make (no options) finish successfully, but the build fails when doing $()-style command substitutions, claiming that the trailing paren is unexpected: % echo $(echo hiya) bash: command substitution: line 9: syntax error near unexpected token `)' bash: command substitution: line 9: `echo hiya)' % Note that other approaches to command substitution seem to work: % echo $(echo hiya > ) hiya % % echo `echo hiya` hiya % Repeat-By: Install cygwin (ver 3.1.0-1) Install cygwin-devel (ver 3.1.0-1) Install autoconf2.5 (ver 2.69-4) Install autoconf (ver 13-1) git clone https://github.com/bminor/bash.git cd bash ./configure make ./bash echo $(echo hiya)
Re: bash uses tmp files for inter-process communication instead of pipes?
On Tue, Oct 7, 2014 at 2:07 AM, Linda Walsh wrote: > > > Pierre Gaston wrote: > >> >> b=<<<$a is not doing anything so I wonder how much value this example has. >> > --- > I wondered about that.. think that was meant to be the > b=<<<($a) w/o the copy that greg said was pointless. > >> >> A pipe means 2 different processes, a tempfile for a heredoc does not. >> > > First) we are talking 2 separate processes... > That I fit those into a heredoc paradigm was already a kludge. > > originally I had, (and wanted) > > producer-func call it prod() > and process-func+store-in-global for future > > i.e. producer|process-func -> vars... but I want the vars in the parent... > so > > processfunc <|<(producer) -- now process can store results but it's using > bogus magic called "process substitution"... naw... > it's a LtR pipe instead of a RtL pipe. or > > parent <|<(child) pipe > > instead of the standard: > > child|parent pipe. The parent being the one who's vars "live" on > afterwards. > > I thought I was getting rid of this bogus problem (which shouldn't > be a problem anyway -- since it's just another pipe but with parent > receiving > the data instead of child receiving it) by storing it in a variable > transfer form > <<<($VAR)... cuz was told that didn't involve a voodoo > process-substitution. > > But it involves a heredoc that even though /tmp and /tmp/var are writeable, > BASH can't use. Either it's writing to //network or trying to open a > tmp file in the current (/sys) directory... eitherway is buggy. > > But a heredoc is just reading from an in-memory buffer. That bash is > going the inefficient route and putting the buffer in "tmp", first, is > the 2nd problem you are pointing out -- why do people who want a heredoc > need a fork OR a tmpfile? The output I generated is < 512 bytes. Would > it > be too silly to simply put any heredoc output write it to any file? shopt heredocsize=XXX[KMG]... and overflow to tmp > if needed. > > But more basically (no limits need be implemented): > why there is there a difference between : > > parent producer >|> child reader >vs. > parent reader <|< child producer > > ??? > > If you want to ask your Q, you should be asking why fork OR *tmpfile. > > In my case, Why do I need a voodoo process that can't be done with pipes.. > cuz I'm pretty sure a parent can spawn children and then read from them > just as easily as write to them. > > > > > > Besides your comparison is simply ludicrous, bash provides several >> mechanisms do to several very different things. >> > --- > Having several that would work woudl be nice. Um... having 1 that would > work even... how do you turn around parent/child I/O and get the vars on > the > other side without heredoc or procsub? Why no pipes? > > >
Re: bash uses tmp files for inter-process communication instead of pipes?
On Tue, Oct 7, 2014 at 2:25 AM, Dave Rutherford wrote: **it.. sorry for the fat finger post. Gmail puts the tiny formatting options right next to the big SEND button. Ratzen fracken.
bash-2.05b-013 appears to not work
We have been compiling some of the older versions of bash to fix vulnerabilities, and for the most, has been working. However, when we patch the 013 patch for CVE-2014-7187, and run the nested loop, it's still showing as vulnerable. Has anyone else had a similiar experience? Thanks for the help, D
Re: bash-2.05b-013 appears to not work
I guess that would help. I meant to include that in the initial mail,
but alas, running in 50K directions.
Locally we are using:
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in
{1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"
If we run the test via ssh, it is showing patched, however locally is
still showing vulnerable.
Thanks Eric,
Dave
On 10/16/14, Chet Ramey wrote:
> On 10/16/14, 5:02 PM, Dave Kalaluhi wrote:
>> We have been compiling some of the older versions of bash to fix
>> vulnerabilities, and for the most, has been working.
>>
>> However, when we patch the 013 patch for CVE-2014-7187, and run the
>> nested loop, it's still showing as vulnerable.
>>
>> Has anyone else had a similiar experience?
>
> Since the code that had the off-by-one error was not even in bash-2.05b,
> I'm skeptical that it's vulnerable.
>
> --
> ``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-2.05b-013 appears to not work
Awesome - Thanks everyone for the help! I will forward these responses
on to the security group. But again, Thank you everyone!!!
-Dave
On 10/17/14, Andreas Schwab wrote:
> Eric Blake writes:
>
>> The following is a better test for whether CVE-2014-7187 can be
>> exploited to remotely attack your system:
>>
>> f='() { echo vulnerable; } bash -c f
>
> Missing quote character.
>
> f='() { echo vulnerable; }' bash -c f
>
> 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: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 9:45 AM, Eduardo A. Bustamante López wrote: > On Wed, Jan 14, 2015 at 09:33:31AM -0500, d...@evilpettingzoo.com wrote: > [...] >> Bash Version: 4.2 >> Patch Level: 37 Also tested on 4.3.30 > [dualbus@dualbus ~]$ mkdir a; >a/a\ a.txt You didn't create any ambiguity there. It seems to be a partial requirement. > [dualbus@dualbus ~]$ echo ~/a/a [completes] > [dualbus@dualbus ~]$ echo ~/a/a\ a.txt > /home/dualbus/a/a a.txt > [dualbus@dualbus ~]$ echo ~/a/a\ a [completes] > [dualbus@dualbus ~]$ echo ~/a/a\ a.txt > /home/dualbus/a/a a.txt > > Are you using any supplementary programs, like bash-completion? I don't think so, unless Debian turned it on for me. Note that without a\ a.odt there, $ ls ~/a/a[completes to a\ a.txt] but $ ls ~/a/a\ [does not complete]
Re: Tab completion breaks for tilde-paths with filenames containing space
On Wed, Jan 14, 2015 at 10:14 AM, Eduardo A. Bustamante López wrote: > Can you test with: > bash --norc --noprofile -i It is working in this case. The difference seems to be in direxpand. $ shopt -s direxpand; shopt direxpand direxpand on $ vi ~/a/a\ [nothing] $ shopt -u direxpand; shopt direxpand direxpand off $ vi ~/a/a\[expands to] $ vi ~/a/a\ a. a a.odt a a.txt Is this expected?
Re: Memory leak in wait
On Mon, Mar 2, 2015 at 2:33 AM, Jean Delvare wrote: > Which brings another question: is there any plan to implement sleep as > a bash builtin? It's already available as a loadable builtin (examples/loadables/sleep.c).
Re: [Bug-readline] Problem with CTRL-z and readline()
On Sun, 2015-03-01 at 20:14 -0500, Chet Ramey wrote: > On 2/27/15 12:10 PM, Dave Anderson wrote: > > > > This issue was first reported with respect to the crash utility, > > which is an interactive program that uses the readline library. > > > > The problem occurs only if the crash utility is run from within > > an executable bash script, i.e., like so: > > > > $ cat doit > > crash > > $ > > > > If crash is invoked as above, the crash utility does its initialization > > and eventually calls readline(). Then, if CTRL-z is entered, the parent > > bash shell itself is blocked, but the crash utility spins at 100% cpu usage. > > Debugging it shows that the crash utility is stuck spinning in the readline > > libary's _set_tty_settings() function, where the tcsetattr() call repeatedly > > fails with an EINTR, where _rl_caught_signal contains SIGTTOU. > > > > But taking the crash utility out of the picture, I can reproduce it with > > readline-6.3.tar.gz, where I simply build it with "configure; make", then > > go into the examples subdirectory, and enter "make". If I then put the > > simple "rl" command in script file, and do the same thing, this happens: > > > > $ cat doit > > ./rl > > $ ./doit > > readline$ ^Z > > [1]+ Stopped ./doit > > $ > > $ top > > top - 12:02:33 up 23:12, 5 users, load average: 0.37, 0.09, 0.04 > > Tasks: 159 total, 2 running, 154 sleeping, 3 stopped, 0 zombie > > Cpu(s): 3.4%us, 21.6%sy, 0.0%ni, 75.0%id, 0.0%wa, 0.0%hi, 0.0%si, > > 0.0%st > > Mem: 3917056k total, 3709052k used, 208004k free,88732k buffers > > Swap: 4063228k total,0k used, 4063228k free, 3049316k cached > > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > > > 12336 root 20 0 100m 1016 788 R 100.0 0.0 1:12.13 rl > > 1 root 20 0 19356 1532 1216 S 0.0 0.0 0:02.89 init > > 2 root 20 0 000 S 0.0 0.0 0:00.02 kthreadd > > 3 root RT 0 000 S 0.0 0.0 0:00.19 migration/0 > > ... > > > > > > If I attach gdb to the rl process above, it shows the same ultimate trace as > > the spinning crash utility does: > > > > # gdb -p 12336 > > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6) > > Copyright (C) 2010 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-redhat-linux-gnu". > > For bug reporting instructions, please see: > > <http://www.gnu.org/software/gdb/bugs/>. > > Attaching to process 12336 > > Reading symbols from /root/readline-6.3/examples/rl...done. > > Reading symbols from /lib64/libtinfo.so.5...Reading symbols from > > /usr/lib/debug/lib64/libtinfo.so.5.7.debug...done. > > done. > > Loaded symbols for /lib64/libtinfo.so.5 > > Reading symbols from /lib64/libc.so.6...Reading symbols from > > /usr/lib/debug/lib64/libc-2.12.so.debug...done. > > done. > > Loaded symbols for /lib64/libc.so.6 > > Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from > > /usr/lib/debug/lib64/ld-2.12.so.debug...done. > > done. > > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > > 0x0033f52dff48 in tcsetattr (fd=0, optional_actions= > out>, termios_p=0x62cb60) > > at ../sysdeps/unix/sysv/linux/tcsetattr.c:84 > > 84 retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios); > > (gdb) bt > > #0 0x0033f52dff48 in tcsetattr (fd=0, optional_actions= > optimized out>, termios_p=0x62cb60) > > at ../sysdeps/unix/sysv/linux/tcsetattr.c:84 > > #1 0x00406f8d in _set_tty_settings (tty=0, tiop=0x62cb60) at > > rltty.c:476 > > #2 0x00406fe3 in set_tty_settings (tty=, > > tiop=) at rltty.c:490 > > #3 0x004072d0 in rl_deprep_terminal () at rltty.c:688 > > #4 0x00413352 in rl_cleanup_after_signal () at signals.c:536 > > #5 0x00413731 in _rl_handle_signal (sig=20) at signals.c:232 > > #6 0x004137e5 in _rl_signal_han
Re: eval a=b\ c
OK, I can make it to work in bash if I say
echodo a=b\\ c
but then zsh tries to execute c. Can’t win.
The problem is: how do I write this function so that it can be invoked
identically in zsh and bash with identical results of setting a variable to a
value with a space in it?
> On 2015-05-26, at 1:04 AM, Andreas Schwab wrote:
>
> d...@yost.com writes:
>
>>eval$@
>
> You are expanding a shell parameter unquoted. Never do that unless you
> know what you are doing.
>
> eval "$@"
>
> 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."
On 2015-05-25, at 6:12 PM, Dennis Williamson
wrote:
> I'm trying to put a command in a variable, but the complex cases always fail!
> : http://mywiki.wooledge.org/BashFAQ/050
>
> Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048
>
> On Mon, May 25, 2015 at 2:33 PM, 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-unknown-linux-gnu'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/bash/4.3.39/share/locale'
> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash-4.3
> -I../bash-4.3/include -I../bash-4.3/lib -g -O2
> uname output: Linux s6.millcomputing.com 2.6.32-504.16.2.el6.x86_64 #1 SMP
> Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 4.3
> Patch Level: 39
> Release Status: release
>
> Description:
>
> # Echo the arguments, then execute them as a command.
> function echodo() {
> if [[ -n $ZSH_VERSION ]] ; then
> echo "[ ${(q)@} ]"
> eval${(q)@}
> else
> echo "[ $@ ]"
> eval$@
> fi
> }
> echodo echo b\ c
> echodo a=b\ c
> echo $a
>
> The result in zsh is:
> $ echodo echo b\ c
> [ echo b\ c ]
> b c
> $ echodo a=b\ c
> [ a=b\ c ]
> $ echo $a
> b c
> $
>
> Bash gets an error:
> $ echodo echo b\ c
> [ echo b c ]
> b c
> $ echodo a=b\ c
> [ a=b c ]
> bash: c: command not found
> $ echo $a
>
> $
>
> I can't find a way to implement echodo in bash. Apparently this is because
> bash is unable to expand a variable with quoting intact, as zsh can do with
> its (q) expansion flag.
>
> Bash behaves differently in this case::
>
> $ echodo export a=b\ c
> [ export a=b c ]
> $ echo $a
> b
> $
>
>
> Repeat-By:
>
>
>
> Fix:
>
>
>
>
> --
> Visit serverfault.com to get your system administration questions answered.
>
Re: Bug, feature or just the correct behaviour (stat'ing -bash down the PATH)
On Tue, Jun 2, 2015 at 9:08 AM, Wheatley, Martin R <
martin.wheat...@ccfe.ac.uk> wrote:
> a truss of "bash -ls" shows it stat'ing '-bash' in each of the directories
> in PATH...
>
> 11933: stat64("/usr/bin/-bash", 0xFFBFEBE8)Err#2 ENOENT
> 11933: stat64("/usr/sbin/-bash", 0xFFBFEBE8) Err#2 ENOENT
> 11933: stat64("/usr/dt/bin/-bash", 0xFFBFEBE8) Err#2 ENOENT
> 11933: stat64("/home/USER/bin/-bash", 0xFFBFEBE8) Err#2 ENOENT
>
> Why does bash do all these 'stat()' system calls? We tried providing an
> executable '-bash' at one of the locations but it didn't appear to have
> any effect.
I believe this is bash trying to set the BASH environment variable.
You say creating a file `-bash' has no effect, but how would
stat return ENOENT if there were a file `/usr/bin/-bash'?
If this is on the local machine, it should be searched (and found)
before any NFS directories are checked. What other
consequences this might have I'm not sure. I don't think bash
uses BASH for anything.
Could you send a truss of the case where /usr/bin/-bash
exists and is executable?
> If one of the directories in the PATH is on an NFS server that is
> 'down' then bash hangs - which disables a shell which would otherwise
> be usable.
It is ironic yet somehow appropriate that a fusion energy center
should be having such a 1997 sort of problem today. But
truly, my sympathies. :-)
Dave
Re: remaking bash, trying static, glibc refuses static...?
On Wed, Aug 19, 2015 at 5:55 PM, Linda Walsh wrote: [cut a lot about dynamic linking and the linux kernel] > Even bash can load many of it's builtin's dynamically -- but if they > aren't there, it could use the same named-programs -- and I don't > think it "falls-over" and dies if it can't dynamically load a builtin -- > it just looks for the same name in the path. There are loadable builtins but I don't believe it is true that they can magically self-load as you describe. The closest this comes to the truth is that many builtins have corresponding programs in /bin, for the use of programs that don't have them builtin or for entities that might naïvely search the PATH looking for things which are legal to execute. (Some unices even include a /bin/cd for that reason, as pointless as that would otherwise be.) Did the rest of your message have anything to do with bash? You were trying to build a static version... you've been told how... was there more?
Re: why must bash zap last search string just because we hit ^C?
On Sat, Oct 17, 2015 at 11:19 PM, 積丹尼 Dan Jacobson wrote: > > "DW" == Dennis Williamson writes: > > DW> Or just open a new terminal rather than interrupting an in-progress > search. > > I am on a device where opening a new terminal is a lot of trouble. > Can you run gnu screen? ^A-c will get you a new shell session in the existing terminal emulator (it will use a new terminal device, though, if that's what you care about.)
Re: Future date
On Sun, Jan 24, 2016 at 5:30 PM, Val Krem wrote:
> I am trying to get a variable that combines the next month(Feb) and
current year (2016) from the current date
[...]
> temp_date=$(date | awk -F ' ' '{print $2,$6}' | tr -d ' ')
Wow, that's overkill. You don't need the -F ' ' options to awk, since
that's the default. You don't need tr to remove the space because
awk will happily not print one if you omit the comma.
And you don't need awk in the first place because date will handle
the desired output directly if you just ask it to.
> I got Jan2016.
> but I want this "Feb2016" next month and current year. How do I do that?
>
> Well at the end of the year, I will have another problem ( ie., to change
it to next year)
date -d 'next month' +%b%Y
Note, I'm not sure that's robust if you call it on, say, the 31st of the
month
if the next month doesn't have 31 days. It might give you two months from
now.
Read the man page for date for further enlightenment.
Re: bug when 'cd ..' to a directory who's parent has been deleted
On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh wrote:
> Chet Ramey wrote:
>> On 2/8/16 9:59 AM, Andreas Schwab wrote:
>>> Chet Ramey writes:
>>>> `cd ..' should fail, since the parent no longer exists, and the
pathname
>>>> canonicalization should fail, since there's presumably no longer a
valid
>>>> path to reach the current directory. No value for $PWD is correct.
>>> ${PWD%/*} would be a reasonable value. FWIW, this is what ksh uses in
>>> this case, it doesn't fail.
>> Why would that be more reasonable than anything else? It references a
>> path that doesn't exist.
> Um...Not exactly. As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).
Really?
11:40:24 dave@Vger:~$ mkdir -p a/a
11:40:30 dave@Vger:~$ cd a/a
[remove a in another window]
11:40:49 dave@Vger:~/a/a$ touch file
touch: cannot touch ‘file’: No such file or directory
Re: copy
Does the /data/test directory exist prior to execution? Otherwise cp is
just copying the result set one at a time to a regular file at /data/test.
You may want to append a forward slash to the directory name, as that will
cause cp to error if the directory doesn't exist instead. Or chain the
command after mkdir -p /output/dir. That will error the same if it isn't a
directory, but also create it if it doesn't exist. Since you are
interested in the files' timestamps, you may way to use --preserve to
preserve them.
So, something like this:
dest_dir='/data/test'; mkdir -p "${dest_dir}" && find . -type f -mtime +10
-name "*.txt" -exec cp --preserve {} "${dest_dir}" \;
Dave Finlay
On Thu, Feb 25, 2016 at 5:41 PM, Val Krem wrote:
> Hi,
>
> I want to copy files which are older than 10 days with the extension file
> name txt.
>
>
> I used the following and it is not doing what supposed to do
>
>
> find . -type f -mtime +10 -name "*.txt" -exec cp {} /data/test \;
>
> can any one help me out?
>
>
Re: Could bash do what make does?
Robert- I wanted to craft a witty retort with a veneer of encouragement that might push your towards trying your proposed endeavor. I could not bring myself to do it after realizing that you are quite serious. I understand your motivations. Build systems are often complicated, opaque pieces of software with many bespoke elements, like syntax, configuration, and macro systems. They often become that way because software projects of any large size start to take on their own arbitrary conventions and requirements that must be handled. We just love to shoot ourselves in the foot. I feel like these are self evident, but perhaps there is a grok gap I'm not seeing. Bash is a shell, a language and an old friend. It is not a build system. Narrowing and/or expanding a piece of software's scope to address problems it isn't concerned with is almost always going to end in tears. See the Unix Philosophy <https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well>: do one thing and do it well. I recommend you attempt this endeavor independently, as a learning experience. Try writing a script and a function library that will allow you to build the Bash project (or something simpler) without Make or Autotools. You will come to understand why the world is as it is. You will come to truly comprehend the dark side of dealing with compilation caches, diverse compiler output, job control, dependency management, packaging, and all the other painful things. After that exercise, take a look at some of approaches people have taken. CMake, Maven, Gradle, and SCons are good projects to look at. Just take a look at how much thought went into Maven's Dependency Version Requirement Specification <https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification>. There is no magic that will lead to the 'Perfect Build System'. It takes well thought out architecture, obsession with details, and a gobs of effort. Even with all that, it will never be perfect or universal. There is always a use case or edge case you didn't deal with. I hope this response was of benefit to you. Dave Finlay On Fri, Dec 2, 2016 at 2:29 AM, Robert Durkacz wrote: > I agree that is the first step to take, but I am supposing that, since > build systems are a big business, some extensions to bash would be worth > doing to take on that market. E.g. I think we would need a concept of lists > of files so as to skip executing a command if all files in the list are > older than some file that is required. > > On 29 November 2016 at 02:21, Dennis Williamson < > dennistwilliam...@gmail.com> wrote: > >> >> >> On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz > > wrote: >> >>> Has thought been given, over the years, to extending bash to do >>> what make does, in the obvious way that I am about to describe? >>> >>> It would be a matter of having chosen build commands do nothing if their >>> outputs are newer than their inputs. For example that is, cc file.c -o >>> file.o should execute normally if file.c is the newer file but do nothing >>> if file.o is newer. >>> >>> Then you would have a deterministic script to build a system that simply >>> skipped steps determined to be unnecessary. >>> >>> It is possible to achieve this without changing bash but it seems like >>> there would be leverage in having bash deliberately support this mode. >>> >> >> >> Use the newer-than test: >> >> source=file.c >> object=file.o >> [[ $source -nt $object ]] && cc "$source" -o "$object" >> >> >> -- >> Visit serverfault.com to get your system administration questions >> answered. >> > >
Re: Could bash do what make does?
There is an onus on you to use the appropriate mailing list. Bug-bash isn't for make-ing your case, bug-bash is for the bugs. Dave Finlay On Dec 6, 2016 15:44, "Robert Durkacz" wrote: On 6 December 2016 at 00:19, Greg Wooledge wrote: > what evidence? > [for shell scripting builds] > I suppose the evidence that you want is in the very same wikipedia article about make, where it says precisely that shell scripts were used before make came along. However, please remember I am here asking a question. I am not promoting any views about these matters which are secondary to the question. There is no onus on me to prove anything. If you are interested in my views and I doubt you are, you can email me privately. I will not indulge you in further public exchanges no matter how provocative you try to be. "Put up or shut up" indeed.
error message lacks useful debugging information
From: daveci...@misguidedmonkey.net To: bug-bash@gnu.org Subject: error message lack useful debuggong information Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sokoke 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Attempting to tun an executable file (not a bash script) with the following command: ./Candle the following error message is reported by bash: bash: ./Candle: cannot execute: required file not found The executable file 'Candle' does exist in the current directory; if it didn't then bash would report a different error. The problem may be a missing dependency. However, the BUG is in bash in that it doesn't offer any useful debugging information. Debugging the issue could go from "nearly hopeless" to "I think I can handle this" if bash simply reported what required file was missing. i.e. path and filename. Repeat-By: Here's how I encountered the problem. You might not be able to reproduce it on your machine, but that doesn't mean that it's not a bug with bash: download: candle_1.1.7.tar.gz from: https://github.com/Denvi/Candle Extract to the folder of your choosing. cd to that folder and execute the bash command: ./Candle From: daveci...@misguidedmonkey.net To: bug-bash@gnu.org Subject: error message lack useful debuggong information Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sokoke 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Attempting to tun an executable file (not a bash script) with the following command: ./Candle the following error message is reported by bash: bash: ./Candle: cannot execute: required file not found The executable file 'Candle' does exist in the current directory; if it didn't then bash would report a different error. The problem may be a missing dependency. However, the BUG is in bash in that it doesn't offer any useful debugging information. Debugging the issue could go from "nearly hopeless" to "I think I can handle this" if bash simply reported what required file was missing. i.e. path and filename. Repeat-By: Here's how I encountered the problem. You might not be able to reproduce it on your machine, but that doesn't mean that it's not a bug with bash: download: candle_1.1.7.tar.gz from: https://github.com/Denvi/Candle Extract to the folder of your choosing. cd to that folder and execute the bash command: ./Candle
Re: error message lacks useful debugging information
I want to thank all of you for taking this issue seriously. I'm sure you all agree that when something fails, the error message should provide useful information about what went wrong. If bash simply doesn't have the information because the kernel didn't provide it, then perhaps I should throw this to the kernel developers. I understand that it might not seem like a bug in the usual sense, but I hope that you agree that it's something straddling the line between bug and "issue" and really is worth fixing. I don't want to get on a soapbox, but it's an example of why linux hasn't acquired the share of desktop users that it should. Thank you again for your time. David Cigna On 10/5/23 01:04, Phi Debian wrote: Since we are on the error path (not the perf path) may be the shell could go the extra miles and try some more diag, has it does for shebang, on ENOENT, the shell could try to open the a.out, if OK try some other euristics, at least the trivial one i.e the multilib case that seems the most disorientating one, the wrong arch (arm on intel) is already correctly handled, then 'may be' try an ldd (if ldd exist) to mention possible missing libs, all this leading to yet another 'error message' to be entered in the NLS... Or simply a reword of the current implementation bash: ./Candle: cannot execute: required file not found bash: ./Candle: cannot execute: Possible arch mismatch or missing shared libs Assuming no QA test already match the "required file not found", if so it would require yet another compat flag... With this more explicit error message the OP at least have some clue to of what to look for.
