t 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
l 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:/
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:
co
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 ex
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 comma
quot;}" 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
__
; (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
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 i
ould 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-ba
"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
nce the : inserted by completion should probably
be backslah-escaped, but I don't know whether it would be bash or your
completion function that's responsible for adding the backslash.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lis
e; 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
on 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
myfunc qwe:qwe:o
>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
'/
"
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
t;#! /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
o 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
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
inner command running in a separate process.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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
t 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_number"p /tmp/results)
> #We change to dir stored in the path variable
>
> cd $path
Quotes would be useful here, in case you
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 mai
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
__
"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
>
7;"
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
"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
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 when this is enabled?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
e it into a 'while read' loop, and then after the loop access any
> variables set within the while loop.
Can you explain what was unsatisfactory about the alternatives given
in the FAQ, so we have a better idea of what would be acceptable?
Here's one possibility:
... | { while ..
Richard van der Leeden <[EMAIL PROTECTED]> wrote:
> The examples in the FAQ do work for the their examples, but I can't figure
> out a clean way to implement it with a while loop when reading in lines from
> the output of a piped command(s).
The redirection applied to "read" in those examples woul
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> while ...; do var=...; done <> $(generate-input-for-while)
>> EOT
>> use "$var"
>
> This has the disadvantage that generator and consumer no longer run
> co
[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
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
:~$
Yes. This always puts the prompt at the beginning of the line, and
still lets you distinguish newline-terminated output from unterminated
output.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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
ct result, then yes. But if the goal is only to detect overflow
and print a warning, then that can still be done without arbitrary
precision.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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
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
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> It seems like there should be a way to delete the first match in pure
> sed, but I didn't figure it out in the few seconds testing I did.
sed '/foo/{x;/^$/d;}'
paul
___
Bug
he
for loop:
old_ifs=$IFS
IFS=$'\n'
set x `cat "$i"`
shift
IFS=$old_ifs
for j in "$@"; do
...
done
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
t;). You can refer to
the first argument as $1 (see "Positional Parameters", under
"PARAMETERS").
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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
<[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 fo
o express
anything you didn't want to do, it also wouldn't be able to express
many things that you want to do.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
ts, [...]
>
> But set() is not a simple command, it is a function definition, no?
Right, so defining the function should work, but calling it should
not.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
t;`
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
ust 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
Nic James Ferrier <[EMAIL PROTECTED]> wrote:
> Using bash 2.05, does anyone know of a way to get a trace of what's
> happening inside a function?
You can add "set -x" at the top of the function body. I don't know of
any way to get a similar effect wi
[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.or
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:/
ld 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
[EMAIL PROTECTED] wrote:
> XXX=10; { XXX=20; } | read; echo $XXX
>
> XXX=10; { XXX=20; }; echo $XXX
>
> I suppose both of them should output '20' but the first one outputs
> '10'. Is it feature of bug?
This is normal. It's ex
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
p the backslash as part of the regexp.
This will work in both versions:
pattern='^\.*/'
[[ ! $V =~ $pattern ]] && echo not
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
et 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
"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
__
es 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
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
The Wanderer <[EMAIL PROTECTED]> wrote:
> !ls /h
How about: ls /h
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
tions and other special characters are not treated specially if
they are produced by a variable expansion. In this case, you want:
eval "$i"
paul
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
[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 out
; echo $?
bash: foo: Permission denied
0
The last line of output should be 1, not 0.
Fix:
2007-11-02 Paul Eggert <[EMAIL PROTECTED]>
* execute_cmd.c (execute_command_internal): Consider a redirection
failure to be a failure in the last compound com
the message, so it stands alone.
You could keep the message translatable, but move \r\n out into the
surrounding code, so it won't be translated itself.
paul
t in this case. It seems like tail is the offender.
>
> (tail -f < /dev/null | $NETCAT -l -p $LISTENPORT >> $LOGFILE 2>&1) &
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 2>&1)
&
paul
[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
; 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
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
nd has the behavior you expect !(+([0-9])) to have.
> IMHO (please correct me if I'm wrong) this contradicts the usual
> meaning of the '!' operator
Negation is negation, but it has different effects on the overall
result depending on where you place it in the pattern.
paul
> I wanted to leave "myswitch2" as the only thing left in $p;
p=" $p "
p=${p/* myswitch2 */myswitch}
p=${p/ */}
paul
n 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
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
ou 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
"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
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
"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
may contain other
expansions.
paul
"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
"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
rds 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
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
arates 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
as I don't use a
tab width of 8 spaces.
Thanks very much and sorry if this was the wrong place to put the request.
--
cul8er
Paul
[EMAIL PROTECTED]
function definition:
alias ls='ls -l'
shopt -s expand_aliases
function foo
{
ls /
}
paul
ely.
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
27;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
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
mpeg into a subshell instead of read.
paul
g/software/bash/manual/bashref.html>.
That document has the same text:
http://www.gnu.org/software/bash/manual/bashref.html#Double-Quotes
paul
nd sentence to
"The character % introduces a job name, or jobspec." "jobspec" isn't
defined anywhere as fa r as I can see.
paul
"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
checking happens before
displaying the primary prompt, which non-interactive shells don't do.
paul
command. Also, I have tried
> concatenated the replace commands using ";". Even that is not
> working.
sed's "s" command should be terminated with a final "/". If nothing
comes after the "s" command, then you can leave out the final "/", but
in your case, you need it:
sed 's/old1/new1/;s/old2/new2/;...'
paul
"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
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
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
)
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
101 - 200 of 279 matches
Mail list logo