True Logik [EMAIL PROTECTED] wrote:
Is there a way to de-install BASH or set my system back to the way it
was before the install? I really need a working Terminal... :-(
If you installed the OS X package, then that's more of an OS X
question than a bash question. Check in an OS X forum.
Chet Ramey [EMAIL PROTECTED] wrote:
That's what the `--' first argument is for: don't treat any remaining
arguments as possible options.
Does printf have any options? If not is there any point in giving an
error in this case? ISTM SUSv3 requires the first argument to be a
format string,
Chet Ramey [EMAIL PROTECTED] wrote:
The SUSv3 has `none' in the OPTIONS section of the printf description.
The description of that value in the `Utility Description Defaults'
section of the standard requires that commands which accept operands
but not options to recognize `--' and handle it
root wheel [EMAIL PROTECTED] wrote:
echo $10
Use ${10}. man bash:
When a positional parameter consisting of more than a single digit is
expanded, it must be enclosed in braces (see EXPANSION below).
paul
___
Bug-bash mailing list
Norbert Nemec [EMAIL PROTECTED] wrote:
How about using a double star ** to signify recursive globbing, i.e.
globbing for arbitrarily deep paths?
FWIW, zsh already has that.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
Hugh Sasse [EMAIL PROTECTED] wrote:
Where does it normally live?
dirent.h, or another file included there.
glark -r \bDIR\b /usr/include:/usr/local/include
The shell processes one level of escaping/quoting.
glark -r '\bDIR\b' /usr/include:/usr/local/include
paul
Philippe Torche [EMAIL PROTECTED] wrote:
aPipe='|'
eval echo 'titi' $aPipe grep toto | grep titi
This is equivalent to:
eval echo titi | grep toto | grep titi
The whole eval counts as one pipeline element, regardless of what's
inside it, so the top-level pipeline is only connecting two
William Park [EMAIL PROTECTED] wrote:
It would be nice if I can read a file and process it as though it was
here-document text in the script. Mainly, I want variable substitution,
without calling lots of 'sed'.
eval blah EOT
`cat file`
EOT
But this breaks if file contains an EOT line.
paul
[EMAIL PROTECTED] wrote:
I had been using ${HOSTNAME%%.*} in my prompt to show the local
host name portion of my full host name (e.g. localhost instead
of localhost.localdomain). After enabling the nullglob shell
option, this pattern is being replaced by a null
Chet Ramey [EMAIL PROTECTED] wrote:
I am considering manipulating the `environ' variable when bash's list
of exported variables changes. That might be enough to make the libc
getenv() work.
I can't quite tell what's going on in lib/sh/getenv.c, but could you
(if you don't already) use libc's
[EMAIL PROTECTED] wrote:
When sourcing a bash script from a 'parent' script the
parameters/args supplied to the 'parent' script are passed
on to the sourced script (!)
This is the traditional behavior, required for compatibility with
other shells and existing scripts.
Chet Ramey [EMAIL PROTECTED] wrote:
Readline, beginning with version 5.0, reads the stty special character
settings and binds them to their readline equivalents each time
readline() is called. It reads ~/.inputrc once per `program'.
Suggestion: when reading .inputrc, update the stty settings
[EMAIL PROTECTED] wrote:
bash# a=500; b=0$[a]; c=$[b]; echo -e a: $a\nb: $b\nc: $c\n
a: 500
b: 0500
c: 320
man bash, under ARITHMETIC EVALUATION:
Constants with a leading 0 are interpreted as octal numbers.
paul
readline/shlib/Makefile uses INSTALL_DATA to install shared libraries.
INSTALL or INSTALL_PROGRAM would seem more appropriate; at least on
GNU/Linux, gcc creates shared libraries with the execute bit set, and
ldd warns if it is not set.
paul
___
[EMAIL PROTECTED] wrote:
If a command in a pipeline of commands fails, there appears to be no
way of knowing this.
Check the man page regarding the PIPESTATUS array.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
Denis Vlasenko [EMAIL PROTECTED] wrote:
The problem is that svc -d (or manual kill -TERM)
kills bash but nmeter and logger continue to run,
until I kill nmeter manually.
It's best not to put a long-running pipeline in a daemontools run
script, for just this reason (among others). Instead,
Antonis [EMAIL PROTECTED] wrote:
Using ansi escape sequences in the prompt causes Bash to incorrectly
calculate the available width of the terminal and messes-up the command
prompt when a certain amount of characters are typed in.
See entry E3 in the bash FAQ.
paul
fabien [EMAIL PROTECTED] wrote:
when programming an auto-completion with embedded : in the
complete names, the auto-completion does not look good.
By default, : is treated like whitespace for completion, to help
when setting variables like $PATH. Check the man page for
Scott Dylewski [EMAIL PROTECTED] wrote:
I get an error when running:
echo $(( 008 / 2 ))
Numbers starting with 0 are interpreted as octal, and so can only use
digits 0-7. You'll have to strip off the leading zeros to make the
number be interpreted as decimal.
paul
Com MN PG P E B Consultant 3 [EMAIL PROTECTED] wrote:
echo THIS DOES NOT WORK
foo=$(cat exp_test BAD | tr -d V= | grep '[0-9]*')
V=1234
abcd
BAD
0. Since you passed a file name to cat, it will ignore stdin.
1. Since the here-document belongs to the command in $(), the
here-document must
Chet Ramey [EMAIL PROTECTED] wrote:
`echo' now displays an error message on write errors.
In the case of a SIGPIPE trap, is it intended that echo sees EPIPE
before the SIGPIPE handler runs?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
Eric Blake [EMAIL PROTECTED] wrote:
But the RATIONALE (XCU line 35443) states that The ! operator has higher
precedence than the -a operator, and the -a operator has higher precedence
than the -o operator. Therefore, when -a is defined as a unary operator,
an XSI compliant test is required to
Dan Jacobson [EMAIL PROTECTED] wrote:
Must one use \: to make this work?
That, or adjust $COMP_WORDBREAKS to not include :.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Johannes Thoma [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:~/bash/bash-3.1$ zak=`printf '\x0d\x0a'`
As documented in the man page under Command Substitution, this
strips off any trailing newlines from the program's output before
assigning the variable's value. So zak contains only a carriage
[EMAIL PROTECTED] wrote:
a exit inside a loop inside a pipe exits's the loop and not the
script. may bee a error.
This is normal. Each element of a pipeline is run in a child process.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
[EMAIL PROTECTED] wrote:
Normally, the eval builtin used in functions to set variables
makes these variables available globally otutside the function.
However, when the function gets input from a pipline, the variables
are set only locally.
Read the bash FAQ, entry E4.
G C McNeil-Watson [EMAIL PROTECTED] wrote:
If you do an
ls -ld directory/
for some existing directory then the output contains TWO trailling
slashes:
drwx-- 2 pypgcm users 4096 Aug 16 2005 directory//
The directory and the first slash appear in blue on my terminal, trailing
Dan Jacobson [EMAIL PROTECTED] wrote:
No way to hand echo or /bin/echo a NULL.
For /bin/echo, that's because execve() uses null-terminated strings.
For bash's builtin echo, it could be done, but then it would be
inconsistent with external commands, which might be surprising.
paul
Dirk H. Schulz [EMAIL PROTECTED] wrote:
ac=12 dings$ac=wasannersder
-bash: dings12=wasannersder: command not found
Variable names in assignments are not subject to expansion. So since
dings$ac, as-is, does not fit the syntax for variable names, it
isn't treated as an assignment. This will
Dirk H. Schulz [EMAIL PROTECTED] wrote:
Paul Jarc schrieb:
ac=12 eval dings$ac=wasannersder
And how do I reference it then?
ac=12 eval value=\$dings$ac
echo $value
Or:
ac=12 name=dings$ac echo ${!name}
paul
___
Bug-bash mailing list
Bug-bash
Bob [EMAIL PROTECTED] wrote:
XXX='a b c d'
for x in $XXX ; do
echo $x
done
XXX='a b c d'
eval set $XXX
for x in $@ ; do
echo $x
done
If the first element in XXX might start with -, then it takes a
little more work to ensure it isn't misinterpreted as
William Yardley [EMAIL PROTECTED] wrote:
I would still like to know if there's a way to bind ^W to
backward-kill-word within bash, so if anyone has suggestions, I'd
appreciate them.
Check out the bind builtin command in the man page or help bind.
paul
Wolf-Rainer Novender [EMAIL PROTECTED] wrote:
e.g. ls [A-Z]* should yield in all names starting with capital letters.
Does not work! I get all names!
http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021
paul
___
Steve Grubb [EMAIL PROTECTED] wrote:
On Tuesday 04 April 2006 15:51, Chet Ramey wrote:
How about commands whose output may be assigned to shell variables?
Yes, they can be acquired in a number of ways. But what we are trying to do
is
set things up so that people using this in a classified
Charlie Bennett [EMAIL PROTECTED] wrote:
Is this expected behavior?
[EMAIL PROTECTED] .ssh]# [ -f ]
[EMAIL PROTECTED] .ssh]# echo $?
0
Yes. A single argument is considered true if it is not the mepty
string, even if it happens to coincide with the spelling of an
operator. This is how all
Mike Frysinger [EMAIL PROTECTED] wrote:
$ foo=a b c
$ gawk 'BEGIN {foo='${foo}'}'
gawk: BEGIN {foo=a
gawk:^ unterminated string
This is normal. man bash:
# Word Splitting
# The shell scans the results of parameter expansion, command substitu-
# tion, and
Peter Volkov [EMAIL PROTECTED] wrote:
$ [[ string =~ [a-z] ]] echo something
something
[a-z] matches only one charater, but the pattern is not required to
match against the entire string. You can force it to match the whole
string by using ^ to anchor the pattern to the beginning of the
Cai Qian [EMAIL PROTECTED] wrote:
For following code,
sh EOF
read
EOF
I have no idea why will not block.
The read command reads from the shell's stdin, which is the here
document. At the point where the read command is executed, the
shell has already read the read command from the
I wrote:
sh EOF 30
read 3
EOF
Sorry, that first line should be:
sh 30 EOF
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Cai Qian [EMAIL PROTECTED] wrote:
It suggests that cat has not seen EOF (004) generated by echo.
The character 004 is not EOF.
When typing at a terminal which is set to cooked mode, you use the
keystroke control-D to tell the terminal driver that it should send
EOF to the program reading from
[EMAIL PROTECTED] wrote:
Aliases don't work correctly in command substitution when in
noninteractive mode. They do work when in interactive mode.
man bash, under ALIASES:
Aliases are not expanded when the shell is not interactive, unless the
expand_aliases shell
Linda Walsh [EMAIL PROTECTED] wrote:
Two aliases:
alias ls='ls -CFG --show-control-chars --color=tty '
alias dir='ls'
If I type ls dir (created a test dir called dir), I
get:
ls dir
I get:
ls: ls: No such file or directory.
man bash, under ALIASES:
# If the last character of
[EMAIL PROTECTED] wrote:
ls -1 | while read f; do
Read entry E4 in the bash FAQ.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
[EMAIL PROTECTED] (Martin Wheatley) wrote:
(ie commands are only executed when the user hits enter and NOT
executed when an I/O error occurs on the input stream).
EOF is not an error. If there is an error, then certainly bash should
not execute an partial command it has buffered, but that
box [EMAIL PROTECTED] wrote:
void ${NAME}Panel::showEvent(QShowEvent *e) {
...code
}
I want to be able to run my script, have it read the contents of the files
while replacing ${NAME} with a variable that is defined elsewhere in my
script.
NAME=...
eval cat EOT
$(cat template-file)
Andrew Kezys [EMAIL PROTECTED] wrote:
So, when I'm running the shell script that calls on this python script
and end it with ctrl-c, it only ends the shell script, and not the
python script, which continues putting serial data to a file.
Ctrl-C should be sending SIGINT to both bash and python.
mwoehlke [EMAIL PROTECTED] wrote:
I thought the syntax was only two ''s?
gives you a here-document. gives you a here-string. Check
the man page for details.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
mwoehlke [EMAIL PROTECTED] wrote:
Poor Yorick wrote:
The following line does not perform the echo command.
: ${FAKEVAR?} || echo hello
What you probably want is:
[ $FAKEVAR ] || echo hello
That doesn't distinguish between an unset variable and a variable set
to an empty value. If that
John Wenker [EMAIL PROTECTED] wrote:
The following construct _always_ evaluates true, regardless of
whether the file exists or not.
if [ ! -a file ]; then
echo This line always prints no matter what.
else
echo This line never prints.
mwoehlke [EMAIL PROTECTED] wrote:
I *know* '! [ -a file ]' is not portable. I tried to use it in some
script, somewhere, at some time, and it was sometimes treated as history
expansion.
Quoting the ! would take care of that particular problem, but there
are some older shells, like Solaris
Nico Schottelius [EMAIL PROTECTED] wrote:
Please remove the need for -e and ignore -e for a some time, until
it vanished from user programs.
There is too much variation among implementations of echo to ever
hope for uniformity. Different implementations all react differently
to options
Mårten Segerkvist [EMAIL PROTECTED] wrote:
i. e. being able to split a one-liner like:
command1 command2 command3
into several, separate command lines:
You can write that one-liner on multiple lines:
command1
command2
command3
paul
___
Greg Schafer [EMAIL PROTECTED] wrote:
#!/bin/sh
set -e
func () {
false echo false
true echo true
false echo false
}
func
echo done
It never echoes done because func() returns 1.
That's the correct behavior. The last false within the function
does not immediately cause
Greg Schafer [EMAIL PROTECTED] wrote:
Thanks for trying to clarify it for me. Let me put it another way: If I
change Line 1 above to an if/then style statement instead of ie:
if false; then echo false; fi
it works exactly like I'd expect instead of the counter-intuitive behavior
when
Mike Frysinger [EMAIL PROTECTED] wrote:
this little bit of code doesnt work right:
foo() { echo ${1:-a{b,c}} ; }
Brace expansion happens before parameter expansion (man bash,
EXPANSION). So the first } ends the parameter expression, and the
second } isn't special. The result of parameter
Kartik K. Agaram [EMAIL PROTECTED] wrote:
I conclude that the 'logical path' is maintained only by the shell, not in
the filesystem. If I'm right, then the whole notion of logical path is a
leaky abstraction honored only by 'cd -L' (are there any others?). I would
really like to be
Ilya N. Golubev [EMAIL PROTECTED] wrote:
If `0:0', `0i', `0.tar' files exists in current directory, `0:' is
completed with `0\:0' to obtain `0:0\:0'.
Using 3.0.16 or 3.1.17, only 0 is added by completion for me. So I
end up with 0:0, and further TABs show me the three possible
matches. What
Jaqui Greenlees [EMAIL PROTECTED] wrote:
In a recet discussion about ssh, the ida was put forth
to get opnssh to export a variable that defines the
authentication method used. The idea being to limit
access to su use to only those authenticating through
a public / privat key pairing.
is
Nathan Coulter [EMAIL PROTECTED] wrote:
cat 0 | xargs -0 -n2 bash -c '
This is beside the point, but 0 is a no-op and be removed. Same
for cat |.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
mwoehlke [EMAIL PROTECTED] wrote:
I am trying to figure out how to run a command and pipe the output
through tee, and then check the status of the original command.
This uses a bash-specific feature:
cmd (tee file); status=$?
This should work on any sh:
exec 31 status=`exec 41 { cmd; echo
Chet Ramey [EMAIL PROTECTED] wrote:
Vasily Tarasov wrote:
I suppose I've found a bug;
I need to make this part of the FAQ. The `:' is special to readline: it
splits words for the word completion code.
That explains some of what's going on in this case, but not all. For
the first tab,
Chet Ramey [EMAIL PROTECTED] wrote:
Chet Ramey [EMAIL PROTECTED] wrote:
Also, after two tabs, we have qwe:qwe:o, but further tabs don't add
any more qwe:'s for some reason I don't understand.
Because the colon is still a word break character, and readline passes `o'
to the completion
Lorenzo Viali [EMAIL PROTECTED] wrote:
eval \$CMDFILE\ $list
because i need $CMDFILE to receive more than
one argument; but what happens is that if in the
script's option's arguments, there are substrings like
$i, those variable are expanded
That will also happen within
mwoehlke [EMAIL PROTECTED] wrote:
And since when does '#! /bin/bash' mean use whatever 'bash' you
find in $PATH? Silly me, I thought it meant use '/bin/bash'.
Dave did say hash-bang, but he didn't say #! /bin/bash. Possibly
he's thinking of #!/usr/bin/env bash, which should do what you want.
Karen Etheridge [EMAIL PROTECTED] wrote:
Tilde expansion is not being performed when variables are being evaluated.
That's normal, documented behavior. man bash, EXPANSION:
The order of expansions is: brace expansion, tilde expansion,
parameter, variable and arithmetic
Chet Ramey [EMAIL PROTECTED] wrote:
Hardcoding `/bin/test' is a tricky business:
How about (exec test ...)? Or env test ...?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Com MN PG P E B Consultant 3 [EMAIL PROTECTED] wrote:
But it seems that within a $(...), even shell functions are executed
in a child process. Is this supposed to work that way?
Yes. $() passes the output of the inner command to the outer shell
via a pipe, with the inner command running in a
Nathan Coulter [EMAIL PROTECTED] wrote:
My real goal is to feed data to a function and then source it:
$ cmd_print () { mkfifo zout ; (cat - zout ) ; source zout ; rm zout; }
$ cmd_print EOF
$ date
$ EOF
$
As Andreas said, this will be problematic using a fifo. You could do
it with a
Markos [EMAIL PROTECTED] wrote:
#Delete logo_1.gif string from every line in results_1,
#leaving only the path to prepare for cd step
sed 's/logo_1.gif//' /tmp/results_1 /tmp/results
This would be more precisely expressed as:
sed 's:/logo_1\.gif$:/:' /tmp/results_1 /tmp/results
If you happen
Markos [EMAIL PROTECTED] wrote:
You said that line
cd $path
should be better with quotes to avoid problems with dir names containing
spaces, so did you mean this?
cd $path
Yes.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
agl [EMAIL PROTECTED] wrote:
PS1=$'\[\e]2;\]\h\[\a\]\h:\w \u\$ '
Try this:
PS1=$'\[\e]2;\h\a\]\h:\w \u\$ '
The first \h doesn't move the cursor position, so it should be kept
within \[ and \] along with the escape sequences.
paul
___
Bug-bash
Paul A. Clarke [EMAIL PROTECTED] wrote:
The man page states, for the -c option:
-c string If the -c option is present, then commands are read from
string. If there are arguments after the string, they are
assigned to the positional parameters,
snowcrash+bugbash [EMAIL PROTECTED] wrote:
CMD=$GPG --output revoke.txt --gen-revoke $ME
/usr/bin/expect -c \
spawn `$CMD`;\
stty -echo;\
expect 'Create a revocation certificate for this key? (y/N) ';\
send 'y\n'
You have backticks around $CMD. That means bash will run the gpg
Brian J. Murrell [EMAIL PROTECTED] wrote:
(cat $file)
http://partmaps.org/era/unix/award.html
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Gurjeet Singh [EMAIL PROTECTED] wrote:
1$ cat setenv.sh
#!/bin/sh
alias llrt='ls -lrt'
...
5$ . ./setenv.sh llrt . ./unsetenv.sh
sh: llrt: command not found
Aliases are expanded when a command is read, not when it is executed.
The entire chain of commands forms a single compound command,
Chet Ramey [EMAIL PROTECTED] wrote:
In my opinion, if a system vendor chooses to enable that sort of
functionality (and many do, for all sorts of reasons), then they
need to add something to the documentation noting that.
Could that be done automatically by ./configure when this is enabled?
Andreas Schwab [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Jarc) writes:
while ...; do var=...; done EOT
$(generate-input-for-while)
EOT
use $var
This has the disadvantage that generator and consumer no longer run
concurrently. Process substitution does not have this problem.
True
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] ~ $ hello=hello; echo ${hello:-1}
Read entry E12 in the bash FAQ.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Caleb Cushing [EMAIL PROTECTED] wrote:
the line
FEATURES=parallel-fetch ccache distlocks# userfetch userpriv usersandbox
I was told my bug is not a bug because there was no space in between the #
putting a space does fix the problem but I can't recall that I've ever seen
any documentation
homac [EMAIL PROTECTED] wrote:
cat test.txt | while read s l ; do
Read entry E4 in the bash FAQ:
http://tiswww.case.edu/php/chet/bash/FAQ
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Richard Neill [EMAIL PROTECTED] wrote:
I thought testing for overflow was quite simple?
Isn't it just a case of looking at the carry-bit, and seeing whether it
gets set?
That's usually how it's done in assembly. In C, it's somewhat more
compilcated. For example:
result=a*b;
if (result/a!=b)
Andreas Schwab [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Jarc) writes:
result=a*b;
if (result/a!=b) { report overflow; }
That won't work, since (signed integer) overflow is undefined in C. A
compiler is allowed to optimize the condition to false.
Right, operations would have
matte [EMAIL PROTECTED] wrote:
The count would be sufficient, as each folder will always hold ONLY these
archives, and no hidden files.
Thus, my directory would be:
myArcName_1.tar.gz
myArcName_2.tar.gz
myArcName_3.tar.gz
This will do it, starting the numbering at 0:
set
[EMAIL PROTECTED] wrote:
Specifying the key combo shift+tab is not documented.
Your terminal program probably doesn't distinguish tab from
shift+tab. To check, try running od, and type tab, enter, shift+tab,
enter, and see if od prints the same codes for both.
paul
Matthew_S [EMAIL PROTECTED] wrote:
Can i have something like;
if
difference between dates 5seconds
echo fail
fi
date1=`perl -e 'print time()'`
...
date2=`perl -e 'print time()'`
interval=`expr $date2 - $date1`
if test 5 -gt $interval; then
echo fail
fi
On some systems, you could also
Chet Ramey [EMAIL PROTECTED] wrote:
Anchored pattern matches that specify removing or replacing each match
don't make sense. The combination is meaningless.
It seems meaningful to me, but since only one occurrence could match
an anchored pattern, every match just means the same thing as the
[EMAIL PROTECTED] wrote:
A variable set inside a while loop loses its value if
the while loop is piped to a command, e.g., sed.
This is normal. Read entry E4 in the bash FAQ.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
raner [EMAIL PROTECTED] wrote:
The completion seems to work, but I do not receive the completed filename
from the shell's stdout.
It's written to stderr, not stdout.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
Matthew Woehlke [EMAIL PROTECTED] wrote:
Stephane Chazelas wrote:
[ -n $foo -a -n $bar ]
is not the expression to test whether both $foo and $bar are
non-empty, as it would fail for some specific values of $foo or
$bar (try it when $foo contains = for instance).
Huh? Why would having an '='
[EMAIL PROTECTED] wrote:
XXX=10; { XXX=20; } | read; echo $XXX
It's clear that 'read' is executed as an separate process and its
result (REPLY variable value) is lost but 'XXX=20' command is done by
the same process as 'XXX=10'.
No, every element of a pipeline is executed in its own
[EMAIL PROTECTED] wrote:
My claim is that in the attached script, the 'false' command should
*not* be considered to be a part of the list.
Nevertheless, it is. The current behavior is too well-entrenched to
change it, so the most reliable way to get the behavior you want is to
Jérémy Hervé [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:/usr/bin# httpd -v
-bash: /usr/sbin/httpd: No such file or directory
hash -r will fix that. See help hash and man bash for details.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
[EMAIL PROTECTED] wrote:
foo=
[ -n ${foo} ] echo true
Prints true.
That's the correct behavior.
Should probably print an error, since after the command is
expanded there are only three arguments, so the final ] should
be interpreted as the argument to
hirochiamaru [EMAIL PROTECTED] wrote:
I saw it on a screen shot once, but this gentlemen was able to put the bash
prompt at the bottom of his xterm window with out fill the top portion the
xterm window first.
yes '' | head -n $LINES
paul
TimtheEagle [EMAIL PROTECTED] wrote:
main_auth=7
f=main
t=auth
ile=$f_$t
echo $ile
Either: echo ${!ile}
Or: eval echo \\$$ile\
paul
bengoavs [EMAIL PROTECTED] wrote:
CMDS=(ls -l /tmp/log)
~/child.sh ${CMDS[0]}
child.sh:
for i in $@
do
if [ $i ]; then
echo $i
$i
Redirections and other special characters are not treated specially if
they are produced by a variable expansion. In
Horinius [EMAIL PROTECTED] wrote:
cat test.txt |
while read line
Read entry E4 in the bash FAQ:
http://tiswww.case.edu/php/chet/bash/FAQ
paul
Horinius [EMAIL PROTECTED] wrote:
Paul Jarc wrote:
Read entry E4 in the bash FAQ:
http://tiswww.case.edu/php/chet/bash/FAQ
I've read several times that section but I'm not sure how to use the IFS.
IFS is only useful if you're splitting the fields of the line into
separate variables
[EMAIL PROTECTED] wrote:
./doit: line 29: exec: 3: not found
This is the line where i try to open the file descriptor
for input:
exec ${fd}$inf
Try this:
eval exec ${fd} '$inf'
And likewise, when closing the descriptor:
eval exec ${fd}-
paul
Horinius [EMAIL PROTECTED] wrote:
Is there any pitfall using this solution of yours? You talked about
regular file, what's that supposed to be? Text file vs binary file?
No, just that it doesn't work for pipes, so the data you're reading
has to be in a named file, not produced as the output
1 - 100 of 147 matches
Mail list logo
