Re: Incorrect alias substitution
Vincent Lefevre vinc...@vinc17.org wrote: I get the following errors with bash 3.2.39 under Debian/unstable: bash -c 'alias a=echo OK 2 a /dev/null a' bash: line 1: a: command not found bash: line 2: a: command not found aliases aren't expanded by a non-interactive bash by default. If you do shopt -s expand_aliases, then they'll be expanded. paul
Re: No tilde expansion right after a quotation
Jon Seymour jon.seym...@gmail.com wrote:
If the builtin echo fails it will be because the bash interpreter has
suffered a catastrophic failure of some kind [ e.g. run out of memory
]. Once that has happened, all bets are off anyway.
Probably true, but command substitution forks a separate process, so
that can fail for reasons external to the bash process.
Here's another possibility:
CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
paul
Re: No tilde expansion right after a quotation
Jon Seymour jon.seym...@gmail.com wrote:
On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc p...@po.cwru.edu wrote:
CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
Out of interest, how does one derive that outcome from the documented
behaviour of bash? That is, which expansion rules are being invoked?
It's ${parameter+word}, using $# (which is always set) as the
parameter.
paul
Re: No tilde expansion right after a quotation
Angel Tsankov fn42...@fmi.uni-sofia.bg wrote: How do you know that $# is always set? And what about $...@? To what values are these parameters set outside any function? $# gives the number of positional parameters. If there aren't any positional parameters, then it's set to 0. In the man page, under PARAMETERS, Special Parameters, you'll find: # Expands to the number of positional parameters in decimal. Note that it doesn't say while a function is being executed or when some positional parameters are set. That variable is always set, as are the others listed under Special Parameters. Positional parameters can be used outside of functions: set foo bar; echo $# $@ bash -c 'echo $0; echo $# $@' arg-zero foo bar A more appropriate parameter to use could be $? which, by pure logic, seems to be at least as often set as is $#. They're both always set; pick whichever one you like. paul
Re: No tilde expansion right after a quotation
Jon Seymour jon.seym...@gmail.com wrote:
The manual specifies a rule for ${parameter:+word}, but not
${parameter+word}.
It's there, but easy to miss:
In each of the cases below, word is subject to tilde expansion, parame-
ter expansion, command substitution, and arithmetic expansion. When
not performing substring expansion, bash tests for a parameter that is
unset or null; omitting the colon results in a test only for a parame-
ter that is unset.
paul
Re: Help: Bash script that show you the last file created?
tal396 tal...@gmail.com wrote: Coz its could be find in alot of subdirs like /home/server/backups/local_backups/1-1-2009/server/mysql/1-1-2009.sql /home/server/backups/local_backups/1-2-2009/server/mysql/1-2-2009.sql /home/server/backups/local_backups/1-3-2009/server/mysql/1-3-2009.sql This will show the most recently modified one of those files: ls -t /home/server/backups/local_backups/*/server/mysql/*.sql | sed q paul
Re: Help: Bash script that show you the last file created?
Mike Frysinger vap...@gentoo.org wrote: the op wasnt asking for the time, they were asking for the last created file. and the ls man page talks how to sort by ctime. ctime is the time when the inode was last modified, not (necessarily) the time when the file was created. paul
Re: Option -n not working reliably and poorly documented
Ronny Standtke ronny.stand...@fhnw.ch wrote: The -n option not seem to work. Example with a little stupid nonsense script: --- ro...@ronny-desktop:/tmp$ cat test.sh #!/bin/sh if [ $blah == test] This sort of error can't be caught by -n, because it's part of a specific command, not the shell grammar. Checking for ] is done when the [ command is executed. Since -n disables execution of all commands, [ won't have a chance to check for a matching ]. Another strange thing: The man page of bash does only implicitly mention the -n option in the description of the -D option: This implies the -n option; no commands will be executed. It's documented under the set builtin. paul
Re: Declaring variables as local effects command status $?
Michael Rendell mich...@cs.mun.ca wrote: local x=$( echo hi; exit 20); ret=$? Here you're getting the exit status of local itself, which is 0. If you want the exit status of the command substitution, make that a separate command: local x x=$( echo hi; exit 20); paul
Re: Migrating from tcsh to bash (issues)
Simos simos.li...@googlemail.com wrote:
alias -- ../='cd ..'
alias -- .../='cd ../..'
alias -- /='cd /'
You can do those as shell functions:
../() { cd ../; }
.../() { cd ../..; }
/() { cd /; }
2. An issue with PS1 is that there is no \w or \W version that can
expand the ~. My aim is to get to show the full pathname at all times.
Use $PWD.
I don't know about #3 or #4.
5. Is there an option in bash to print the exit value of commands?
You can use $? or ${pipestat...@]} in $PS1 or $PROMPT_COMMAND.
paul
Re: truncating the path in the bash prompt?
Matthew Woehlke mw_tr...@users.sourceforge.net wrote:
Actually, a feature that would be REALLY helpful is a way to specify
certain directory strings that should be abbreviated.
PS1='...$(mypath)...'
mypath() {
case $PWD/ in
/usr/local/src/kde/svn/trunk/*)
printf %s ${PWD/#\/usr\/local\/src\/kde\/svn\/trunk/\$src\$};;
/usr/local/build/kde/svn/trunk/*)
printf %s ${PWD/#\/usr\/local\/build\/kde\/svn\/trunk/\$build\$};;
*) printf %s $PWD;;
esac
}
paul
Re: ${parameter+word} not documented in bash.info or bash(1)
Martin Schwenke mar...@meltin.net wrote:
Neither bash.info or bash(1) documents parameter expansion of the
form:
${parameter+word}
It's documented, but it's easy to miss. Just before the list of
parameter expansion forms is this paragraph:
In each of the cases below, word is subject to tilde expansion,
parameter expansion, command substitution, and arithmetic
expansion. When not performing substring expansion, bash tests
for a parameter that is unset or null; omitting the colon
results in a test only for a parameter that is unset.
paul
Re: Can't execute file from command line
men8th t...@avacta.com wrote: t...@ggeom:/usr/local/SunStudio12ml-linux-x86-200709-ii/sunstudio12/prod/bin$ ./CC bash: ./CC: No such file or directory However, the file clearly is there. Here is an extract of ls -l The problem could be that CC is a script, and the interpreter on its #! line does not exist. (Or it could be an ELF binary, and the ELF dynamic loader specified in the binary doesn't exist.) This can happen if the script has CRLF (carriage return + line feed) line endings instead of just LF. The carriage return character is treated as part of the interpreter filename. Removing the carriage returns would fix that. The problem is unlikely to be in bash itself, so if the above suggestion doesn't help, you're more likely to find the answer in a forum for Sun Studio than for bash. paul
Re: command not found on remote server
Dolphin06 [EMAIL PROTECTED] wrote: Can i do something like this : ssh [EMAIL PROTECTED] export PATH=$PATH:/other path/ ; script param You'd have to quote the sequence of commands that should run on the remote host, so that the local bash and ssh see it as all one parameter: ssh [EMAIL PROTECTED] 'export PATH=$PATH:/other path/ ; script param' paul
Re: command not found on remote server
Bob Proulx b...@proulx.com wrote: Also, using full paths is frowned upon. You mean invoking /directory/some-command directly instead of PATH=$PATH:/directory some-command ? It depends on the situation. If you think some-command is in /directory, but you want to allow for the possibility that it might be somewhere else in $PATH, then augmenting $PATH and invoking some-command by its basename is better. On the other hand, if you know that the some-command you want is definitely in /directory, and if there could be other versions of some-command elsewhere in $PATH that are different from the one you want, then it's best to invoke /directory/some-command by its full path. paul
Re: [severe] access outside simlinked directory
AT-HE [EMAIL PROTECTED] wrote: if you have a simlink pointing to a directory, chdir to that symlink dir, and type something with '..', you access the parent of real directory, not previous simlinked one. That's the kernel's doing, not bash's. When interpreting pathnames relative to the current working directory, the kernel only cares about where you are, not how you got there. It's been that way for as long as Unix has had symlinks, and changing it now would break a lot of programs that expect the current behavior. paul
Re: Possible bug with respect to global variable within block of code when piping the output of later
Thiemo Kellner [EMAIL PROTECTED] wrote: Maybe the piping converts the block implicitly to a subshell. Yes, it does. This is documented in the man page, under Pipelines in the SHELL GRAMMAR section, and in the FAQ, entry E4. paul
Re: Regular experssions are not working in 3.2.39 as in 3.1.17
[EMAIL PROTECTED] wrote: regular expression are broken in 3.2.39 It's not broken; it's different. See entry E14 in the bash FAQ, and check out the compat31 option in shopt. paul
Re: errexit inconsistent behaviour with pipelines
Marcin Owsiany [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2008 at 09:22:30AM -0400, Chet Ramey wrote: This bug only occurs when errexit is enabled and the final element of a pipeline is a simple command that returns a non-zero exit status. Well, if the final element in the pipeline is a simple command, all works as is supposed to. No. It works the way you want it to, but not the way SUS says it should. When it's a-not-so-simple command, like a for or while loop, then it does not terminate the parent. That's the case that's behaving correctly, even though it's not the way you want it to behave. Neither case should terminate the shell. Only a simple command should terminate the shell, and a pipeline is not a simple command, even if its components are. Chet is saying that the next bash release will fix this bug - meaning that true | false will no longer cause the shell to exit. paul
Re: Keep bash output to one line
mikehershey32 [EMAIL PROTECTED] wrote:
Is there a way that i can make new output to the file overwrite the
old file content without stopping the program and restarting the script or
rotating the log file?
{
python -c '
import os
import time
while True:
time.sleep(1)
os.lseek(1, 0, 0)
'
btlaunchmany.py
} output-file
Here, python and btlaunchmany.py both inherit the same file descriptor
from a single shell redirection, which means they share the file
position - changing it in one affects the other.
paul
Re: test -t
Chet Ramey [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Is this a bug? $ t=test #bash builtin $ $t -t ' '; echo $? 0 Doesn't look like it: I think it is a bug, but libc may or may not hide it, depending on the strtol[l] implementation. SUS says: # If the subject sequence is empty or does not have the expected form, # no conversion is performed; the value of str is stored in the object # pointed to by endptr, provided that endptr is not a null pointer. ... # If no conversion could be performed, 0 shall be returned and errno may # be set to [EINVAL]. Note it says errno may be set, not shall. bash seems to assume shall in legal_number() in general.c: errno = 0; value = strtoimax (string, ep, 10); if (errno) return 0; /* errno is set on overflow or underflow */ I think the test should be: if (errno || ep == string) This should be reliable, according to SUS: # If the subject sequence is empty or does not have the expected form, # no conversion is performed; the value of str is stored in the object # pointed to by endptr, provided that endptr is not a null pointer. paul
Re: test -t
[EMAIL PROTECTED] wrote: On (info (coreutils)File type tests, and test(1) man page, we see `-t FD' True if FD is a file descriptor that is associated with a terminal. Well please mention what happens if FD is omitted: bash's help test explains this, if you know where to look: String operators: ... STRING True if string is not empty. Similar language is in bash's man page and coreutils' info documentation. But it wouldn't hurt to add a note to indicate that if no operand is provided, then -t and other operators stop being operators, and are tested as plain strings. $ t=test #bash builtin $ $t -t ' '; echo $? 0 That looks like a bug. bash tries to parse a number from the string and ends up with zero, which is a tty. paul
Re: Maximum limit of pipes in a single command ?
Keshetti Mahesh [EMAIL PROTECTED] wrote: I followed the syntax properly. But thats not the problem. Problem is how long can the concatenated string can be ? If it's too long to fit in that command line, you could pass it this way: sed -f (echo 's/old1/new1/;s/old2/new2/...') paul
Re: CDPATH reports to stdout and even non-interactively
Geoff Kuenning [EMAIL PROTECTED] wrote: BASH_ENVis the cracker's delight. Any setuid program that invokes a Bash script, even indirectly, is completely open to attack. Nope. Look at the -p option for set. BASH_ENV can be used to cause scripts to go haywire, but only with your own account. CDPATH Should be unset in non-interactive mode. Scripts are unlikely to want to inherit CDPATH; if they want to use it they can easily set it themselves. Not necessarily. In some cases, it may be that a script relies on the inherited CDPATH as a way for the user to tell it where to operate - that is, a script might treat it just like HOME, PATH, and TMPDIR. In cases like that, the script can't know what value the user wants CDPATH to be set to. (Though it's still true that many other scripts don't treat it that way and may be vulnerable to abuse.) CDPATH and GLOBIGNORE could at least be added to the -p handling, I'd say. The trouble with unsetting an inherited variable in non-interactive shells is that it screws up the situation where an interactive shell invokes a non-interactive shell, which then invokes another interactive shell. The second interactive shell should get the same environment that the first one had, but it won't if the non-interactive one in between makes changes for its own benefit. So a non-interactive shell could simply ignore the inherited value without modifying the environment that it passes on to subprocesses, but that carries surprises of its own. MAILShould be ignored in non-interactive mode (and probably already is). Right. (Likewise for MAILPATH.) Mail checking happens before displaying the primary prompt, which non-interactive shells don't do. paul
Re: function name bug ?
christophe malvasio [EMAIL PROTECTED] wrote:
cbz (){ echo why 'cbz' not a valid function name ?;}
bash: syntax error near unexpected token `('
It works for me. What does alias cbz say for you?
paul
Re: inconsistent treatment of backslash-bang
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Chet Ramey wrote: This is from the man page, in the QUOTING section: No idea about that. GNU project folks are well-known for deprecating man pages. I go by the reference manual http://www.gnu.org/software/bash/manual/bashref.html. That document has the same text: http://www.gnu.org/software/bash/manual/bashref.html#Double-Quotes paul
Re: bash: request for a way to return variables to the parent of a subshell
Richard Neill [EMAIL PROTECTED] wrote: the aim is to parse the output of ffmpeg -formats to see whether certain codecs are supported by that build. I'd use something like: while read line; do ... done (ffmpeg -formats 2/dev/null) That puts ffmpeg into a subshell instead of read. paul
Re: inconsistent treatment of backslash-bang
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Chet Ramey wrote: I already explained that bash follows csh as closely as possible in its history expansion implementation. Well, it doesn't: Sure it does: in your examples, bash tries history expansion in exactly the same cases as tcsh. Where they differ is in escape/quote handling, since bash comes from the Bourne shell tradition, and tcsh comes from the completely incompatible C shell tradition. It's not at all surprising that merging behaviors from these two disparate shells would result in some rought edges. Either \ acts as an escape or it doesn't You would like that to be true, as would lots of other people. But the current behavior is too well-entrenched to change now without breaking lots of people's expectations, based on bash's past behavior. It's not going to change. You are free to patch your own copy of bash, or use a different shell that aims for self-consistency over historical consistency. paul
Re: inconsistent treatment of backslash-bang
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: It's not going to break any executable scripts, since it has already been pointed out to me that history expansion doesn't happen in scripts. History expansion doesn't happen in scripts *by default*, but it can be enabled explicitly. paul
Re: inconsistent treatment of backslash-bang
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: pk wrote: This is documented in man bash, and only happens in interactive shells (not scripts). I just tried putting my six cases into a script, and I get exactly the same sort of output as interactively. How did you invoke the script? If you do . ./script, then the script commands are being run in the interactive shell, so you'll get the same behavior as if you typed them directly. ./script will run those commands in a new, non-interactive shell. paul
Re: alias expansion with functions in non-interactive mode
Marco [EMAIL PROTECTED] wrote:
I couldn't find any information on it, but I'm noticing alias expansion
is not happening in non-interactive mode within a function with
expanded_aliases turned on. Is this a know problem, or am I missing
something?
Alias expansion happens when a command is read, not when it is
executed. So in this case, it happens when the function is defined,
which means you would need to define the alias and have expand_aliases
turned on before the function definition:
alias ls='ls -l'
shopt -s expand_aliases
function foo
{
ls /
}
paul
Re: spaces in the shebang interpreter path
Felix Schwarz [EMAIL PROTECTED] wrote: I'm not able to specify an interpreter in a shebang line if the path to this interpreter contains spaces. It's actually the kernel that interprets that line, not bash. The historical behavior is that space separates the interpreter from an optional argument, and there is no escape mechanism, so there's no way to specify an interpreter with a space in the path. It's unlikely that this would ever change, since that would break existing scripts that rely on thecurrent behavior. paul
Re: function names which contain a 'dash' character
Jan Schampera [EMAIL PROTECTED] wrote: Stephane Chazelas wrote: Note that bash didn't have to. POSIX allows a shell to accept any character in a function name, but it says one shouldn't use those in a POSIX script, which is different. I'm not a POSIX expert, and this is the SUS, but I read: | The format of a function definition command is as follows: | fname() compound-command[io-redirect ...] | The function is named fname; the application shall ensure that it is a | name (see the Base Definitions volume of IEEE Std 1003.1-2001, Section | 3.230, Name). The application is the script, not the shell, so this is consistent with Stephane's statement. paul
Re: for ... in ... do ignores escape characters
luiscolorado [EMAIL PROTECTED] wrote: 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 Unquoted `` expansions are split into words using $IFS. So if you only want to split on newlines: old_ifs=$IFS IFS=' ' for i in `my-program`; do ...; done IFS=$old_ifs paul
Re: Cursor misplaced while iterating history
João Abecasis [EMAIL PROTECTED] wrote: $ PS1='\e[0;[EMAIL PROTECTED] \W]$i\[\e[m\]' See entry E3 in the bash FAQ: http://tiswww.case.edu/php/chet/bash/FAQ paul
Re: Cursor misplaced while iterating history
João Abecasis [EMAIL PROTECTED] wrote: $ PS1='\e[0;[EMAIL PROTECTED] \W]$i\[\e[m\]' Sorry, ignore the previous message - you're missing \[ before the first escape sequence. paul
Re: shorthand attempt at 'basename file .ext'
Linda Walsh [EMAIL PROTECTED] wrote:
echo ${{f##*/}%$ext} (but: -bash: ${{f##*/}%$ext}: bad substitution)
Do I need to use an intermediate variable
Yes. Unfortunately, the expansion operators work directly on
variables - not on arbitrary strings which may contain other
expansions.
paul
Re: problems with 'read'ing from a pipe
John Smith [EMAIL PROTECTED] wrote: echo foo | read VAR echo $VAR See entry E4 in the bash FAQ: http://tiswww.case.edu/php/chet/bash/FAQ paul
Re: Which Bash
Charlse Darwin [EMAIL PROTECTED] wrote: i.e. How do I get the latest to be the login shell? You could add exec bash as the last command in ~/.bash_profile. paul
Re: broken pipe
Brian J. Murrell [EMAIL PROTECTED] wrote: It is a shame for this particular reason that head does not (perhaps as an option) consume it's input after displaying the 20 lines. You can do that with sed: ... | sed '21,$d' paul
Re: tricky shell script question
Erik-Jan Taal [EMAIL PROTECTED] wrote:
Now watch the terminal where the script was still running. I would
expect no output to be given, as I assumed the script is read into memory
at startup and not during execution and this is what happens on most
systems. On one server however, the 'bla' is echoed.
There are no guarantees here, except that each top-level statement is
entirely read before being executed. Reading beyond the next command
to be executed can vary from one system to another, depending on stdio
buffering from libc. So if you want to be sure that each execution
isn't affected by edits made while it is running, wrap the whole thing
in a compound statement that exits before returning:
#!/bin/sh
{
...
exit
}
paul
Re: matching !(patterns)
Linda Walsh [EMAIL PROTECTED] wrote:
The longest matching substring (because you use / to start the pattern,
yes?)
No, !() normally uses the longest match, just like *, *(), and +().
s=thomas rich george
Manpage says !() will match anything except one of the patterns.
$s is 1 pattern, no? (no alternation); 1 pattern containing
thomas rich george, yes?
Right.
Then if I use !($s) as the replacement pattern within in the substitute
operator, ( ${s//!($s)/X} ) the !($s) should match any string
except what is in $s (thomas rich george).
It will match the longest substring of $s that is not $s itself -
which is the first N-1 characters of s. With //, it will replace
every match, so the final character will also be replaced, since it is
not the same as all of $s.
So in the substitute, the string to replace (the !($s) part) should
match nothing in my variable $s, so I'd think no replacement would
be done.
You're right that $s as a whole does not match !($s). But that isn't
the only candidate for matching. Every substring is a candidate. The
first position where a match is found is used, with the longest match
starting at that position.
To check whether a string as a whole matches a pattern, instead of
checking for a matching substring, you can use case. (Or, if the
pattern is a literal string with no special characters, you can use
test.)
echo \${s//!($s)/X}\
XX # why two X's? if I use 1 / instead of double:
echo \${s/!($s)/X}\
Xe # why an e afterwards?
With / instead of //, only the first match is replaced.
paul
Re: capturing sub-expressions?
Linda Walsh [EMAIL PROTECTED] wrote: p=-e -p 60 -x --- That's why I wanted the capture -- to pick out the 60 -- where 60 represents a positive integer. The space between the -p and the number is optional. It sounds like you're looking for getopt. paul
Re: Exit application with two function calls
Linda Walsh [EMAIL PROTECTED] wrote: # *1 - using -e stops your script immediately on any error Not any error - only those from simple commands. The subtleties are subtle enough that I avoid -e, and use between all commands instead. paul
Re: unset strangely rejects certain function names eg fu~
[EMAIL PROTECTED] wrote: $ unset fu~ bash: unset: `fu~': not a valid identifier You can use unset -f to unset a function whose name doesn't fit the rules for variable names. paul
Re: Problem with pattern replacing when STRING is an expandable char
Heinz-Ado Arnolds [EMAIL PROTECTED] wrote:
a=111.1
echo ${a//[0-9]/x}
correctly gives xxx.x, but
echo ${a//[0-9]/*}
gives a listing of files in current directory. Seems that the *
is expanded before replacing the pattern.
No, it's expanded afterward, because the variable expansion isn't
quoted. This does what you want:
echo ${a//[0-9]/*}
It workes the right way at least up to bash-3.1.17(1)-release
But if you set
a=111
it doesn't even work in 3.1.17 right.
3.1.17 behaves the same way as 3.2.25. You see a different result
because of a different set of files between the two situations, not
because of the different bash version. If there are no files in the
current directory that match ***.*, then pathname expansion will leave
it unchanged.
paul
Re: Disowned process hangs terminal during logout/exit
Jesse Molina [EMAIL PROTECTED] wrote: Basically, on the two troubled systems, my interactive shell will hang after I've disowned a process. On one other system, everything works as expected. I expect that a disowned process should not hang logout -- disowned means disowned. The terminal will hang around as long as any process has an open descriptor connected to it. disown does not (and cannot) disconnect an already-running process's file descriptors from the terminal. It only affects the relationship between the process and bash, not between the process and the terminal. It seems like it's hanging on stdout since redirecting to /dev/null fixes the problem. You could have the same problem with stdin/stderr. Here is the actual line where I am having trouble. I can't redirect tail's output in this case. It seems like tail is the offender. (tail -f /dev/null | $NETCAT -l -p $LISTENPORT $LOGFILE 21) tail's stderr would still be connected to the terminal in that case. See if this works: (tail -f /dev/null 2 /dev/null | $NETCAT -l -p $LISTENPORT $LOGFILE 21) paul
Re: Problem with reading file and executing other stuffs?
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. The examples in the FAQ are also only useful for reading a single line. If you're reading from a regular file, you can just eliminate the useless use of cat: while read line; do ...; done test.txt paul
Re: try to open file descriptor for input with 'exec' fails
[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
Re: Problem with reading file and executing other stuffs?
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 of another program. But even in that case, you could do it like this: while read line; do ...; done EOT $(data-producer-command) EOT That will also ensure that the last line ends with a newline, but the $() command substitution will also remove any trailing empty lines, which might be a problem, depending on what you're doing. paul
Re: Problem with reading file and executing other stuffs?
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
Re: Running commands from array in a child script
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 this case, you want:
eval $i
paul
Re: Evaluating a variable within a variable
TimtheEagle [EMAIL PROTECTED] wrote:
main_auth=7
f=main
t=auth
ile=$f_$t
echo $ile
Either: echo ${!ile}
Or: eval echo \\$$ile\
paul
Re: Bash Prompt location
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
Re: [ -n ${emptyvariable} ] returns success
[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 -n, thus leaving the command
with a missing ] terminator.
No, the final ] is always taken to be the match for [. Anything in
between has to be parsed consistently with that. In this case, it
means that the test expression includes only one argument, -n.
Since there is only one, it is taken to be an operand, even if it
happens to have the same spelling as an operator. The operand is
tested for being nonempty, which -n is, so the result here is true.
To avoid pitfalls like this, always quote variable expansions. The [[
command is also less tricky.
paul
Re: PATH strange behaviour
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 http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Exit-on-error option does not work as expected
[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 skip -e and add between all commands. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Assigning variable value in right behalf of pipeline has no effect
[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 process. So
the only commands that are executed in the main shell process are
XXX=10 and echo $XXX.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: wrong logical evaluation of expressions involving true or false commands
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 '=' in foo have any effect? I think Stephane meant the exact string =, not any string containing =. $foo is still a string, it should not be subject to word splitting Right, but it is special to the test/[ command. $ [ -n = -a -n z ] bash: [: too many arguments Here, = is interpreted as a binary operator, not as the operand of -n. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash command completion when not connected to a terminal
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 http://lists.gnu.org/mailman/listinfo/bug-bash
Re: variable lost when while loop piped
[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 http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Pattern replacement inconsistency
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 first match. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Timing an operation
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 use date +%s instead of perl, if you prefer. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: backwards menu-complete with shift+tab
[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 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Generating unique file names
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 myArcName_[*].tar.gz myArcName_*.tar.gz if test $1 = 'myArcName_[*].tar.gz' test $2 = 'myArcName_*.tar.gz' then shift fi newname=myArcName_$#.tar.gz If you can assume there are already some files present, numbered from 0, then you can simplify it: set myArcName_*.tar.gz newname=myArcName_$#.tar.gz paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash arithmetic doesn't give error message on wrap.
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) { report overflow; }
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash arithmetic doesn't give error message on wrap.
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 to be performed in unsigned arithmetic
and then adjusted for the proper sign, range chaecking, etc., to get
signed results.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Problem with array element assignment
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
Re: Syntax question
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 saying that mid line comments need a space before the # man bash, in the section COMMENTS: a word beginning with # causes that word and all remaining characters on that line to be ignored In your case, the # is not at the beginning of a word, so it doesn't start a comment. (Quotes don't separate words; a word can be partly quoted and partly not.) paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: parameter expansion malinterpretation
[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
Re: while read subcommand problem
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. The here-document with command substitution also removes any trailing newlines from the output, then adds back just one newline. But it is more portable to other shells. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: /etc/bash.bashrc derivation and misuses
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? paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Just created alias doesn't work in a string of commands
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, which is completely read before any of it is executed, so the alias is not defined yet at the point when it would be expanded. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: reading the first colums of text file
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
Re: can't pass a response from bash script to an app's interactive dialog
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 command first, and the substitute its output in the argument to expect. If you want expect to see literal backticks around the gpg command, escape them with backslashes. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: man page -c explanation clarity
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, starting with $0. I think the phrase arguments after the string is confusing in that the arguments here are really still within the string, not after. bash -c 'printf %s\\n $0 $@' arg0 arg1 arg2 arg3 The string refers to the part which, in this example, is single-quoted, and the arguments are indeed after that, not within it. I'd suggest slightly different wording, such as: ... If argments follow the respective commands within the string, they are... That would suggest to me that arguments in the place of %s\\n in my example are assigned to the positional parameters, which is not true. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: long lines not wrapping correctly in Mac OS X
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 mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Quotes problem ?
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 http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Quotes problem ?
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 to have a directory contining logo_1.gif in its name, your version won't do what you want. sed -n $line_numberp /tmp/results $path doesn't do what you want. It redirects the output of a command to a file. If you want to store the output in a shell variable, use this: path=$(sed -n $line_numberp /tmp/results) #We change to dir stored in the path variable cd $path Quotes would be useful here, in case you have a directory name containing spaces. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: mkfifo and tee within a function
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 regular file, or you can do it without using the filesystem
at all:
cmd_print() { input=`cat` eval $input; }
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Why is this executed inside a subshell?
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 separate process. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: botched configure check for /dev/stdin
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
Re: How to detect bash?
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. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Tilde expansion not performed during variable evaluation
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 expansion and command substitution (done in a left-to-right fashion), word splitting, and pathname expansion. So after parameter expansion, it's too late for tilde expansion. If you know that tilde is the only special character in your variable, you could use eval to pass it through a second round of expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: ...Limitation?
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 $? 4; } | tee file 3`
Or, if you don't want to clobber any descriptors, in case they might
be in use for something else:
: file
{ tail -f file }
pid=$!
{ cmd file; status=$?; }
sleep 1 # give tail a chance to print the last bits that were just written
kill $pid
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents : auto completion doesn't work properly
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, shouldn't the text filled in by completion be qwe\:o instead of qwe:o, since it includes a COMP_WORDBREAKS character? That's how filename completion behaves, so I'd expect the same behavior here. Is the completion function responsible for adding the backslash, or should bash do it? 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. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents : auto completion doesn't work properly
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 function as the partial word to be completed.
I added some echos to the completion function to check, and I see
something different.
$ echo $COMP_WORDBREAKS
'=;|(:
$ _myfunc() {
local cur=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=( $(compgen -W qwe:on qwe:off -- $cur) )
echo
echo
printf '%s\n' cword $cur words [EMAIL PROTECTED] reply [EMAIL
PROTECTED]
echo
}
$ complete -F _myfunc myfunc
$ myfunc TAB
cword
words
myfunc
reply
qwe:on
qwe:off
$ myfunc qwe:oTAB
cword
qwe:o
words
myfunc
qwe:o
reply
qwe:on
qwe:off
$ myfunc qwe:qwe:oTAB
cword
qwe:qwe:o
words
myfunc
qwe:qwe:o
reply
So it looks like the entire word is passed to the completion function;
COMP_WORDBREAKS is not consulted at that point. COMP_WORDBREAKS is
only used to decide how much text to erase before inserting the
completion text. Is that intended? Is the completion function
supposed to take care of splitting the word if it wants that?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: no parameter expansion and no special meaning to control operator
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 $CMDFILE, since that variable is expanded before eval sees it. You could prevent the secondary expansion within $CMDFILE by escaping the $: eval \\$CMDFILE\ $list But that won't help with $list. Option 1: don't use eval. $CMDFILE $list In this case, you'd probably also want to use set -f first to disable filename expansion in the contents of $list (and set +f afterwards to restore filename expansion). $list will still be split at whitespace to produce multiple arguments. The only restriction is that you can't produce an argument containing whitespace. Option 2: quote before eval. When adding an arguemnt to list, quote it first by passing it through this sed command: sed s/'/'''/g 1s/^/'/ \$s/\$/'/ This way, you can include arguments containing whitespace, or any other special characters. They'll be quoted, so eval will only remove the quotes, without further expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: completion hosed by :
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 version are you using? Are you using any programmable-completion customizations? If 1st `:' is a file name separator, the file name prefix to complete is empty, all files in current directory must be considered for completion. That's the behavior I see. If `:' is part of file name, it should be completed with `0', and optionally escaped to distinguish from file name separator. To obtain `0:0' or `0\:0'. That's the behavior you should see if you remove : from $COMP_WORDBREAKS. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: make bash use authentication type?
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 there any way currently to configure bash to use this and limit access to su if the authentication is not through th ky pair, without hurting the transparency of normal ssh access? The shell isn't the right place to enforce access control. The user could simply run su via a different shell, or the env command, etc. Access control for su should be implemendted in su itself. Also, it's easy to circumvent this access control if it's in an environment variable; users can change the environment of their own processes. You could have sshd run the user's session with an extra supplementary group ID, depending on the authentication method. Then you could make su executable by only that group. You wouldn't have to make any coding changes outside of sshd. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: process null-delimited input
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 http://lists.gnu.org/mailman/listinfo/bug-bash
Re: completion inconsistencies involving symlinks
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 told I'm wrong. Sorry, you're not wrong. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: incorrect brace expansion when using default values
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 expansion is not
subject to brace expansion.
$ foo
a{b,c}
This is correct. a{b,c is the default value, and } follows the
parameter expression.
$ foo 1
a}
I get 1}.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: functions and set -e
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 bash to exit, since it is part of the
comound statement. But then the function call itself, which is a
simple command in its own right, has a nonzero exit status, so bash
exits at that point.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: functions and set -e
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 using . That's because the exit status if an if command with a false condition and no else clause is 0, while the status of the command is not. bash is behaving exactly as the documentation says: the function call itself is a simple command, so if it returns nonzero, bash exits. The internal structure of the function is irrelevant. What matters is the exit status of the simple command, not how that status is produced from other, possibly non-simple commands. If you want the function to never cause bash to exit, insert an extra true at the end. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Espace characters need -e, wrong behaviour
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 and backslash sequences. To get portable behavior, use printf. (Or, if you want to be portable to older platforms that lack printf, use cat with a here document.) paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Job queing
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 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug with 'test' built-in.
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. fi -a can act as a prefix unary operator, or an infix binary and operator. When it appears as the second of three arguments (not counting ]) in a test, it's treated as a binary operator, even if the first argument is !. So in this case, ! is test, and as a single string it's only tested for non-emptiness, and so is considered true. Likewise for file. Since both subtests are true, the combined and test is also true. There are a few different ways to get the behavior you want. You could use [ ! \( -a file \) ] or ! [ -a file ], although those are not portable to some other shells. (The behavior of a test is generally more predictable when there are fewer arguments, so I'd go with the second of those two, since it pulls the ! outside the test and leaves only two arguments for the test to examine.) You could also remove ! and switch your then and else clauses, which works with any shell. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug with 'test' built-in.
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 /bin/sh, where the ! command doesn't exist at all, so if this script will have to run in anything but bash, it'd still be good to use one of the other methods. paul ___ 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
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 distinction is important, you can use:
test ${FAKEVAR+set} = set
You can also wrap it up in a function for convenience:
is_set() {
eval test \\${${1?}+set}\ = set
}
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
