Re: stty settings override ~/.inputrc?

[Paul Jarc]

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 to match
as closely as possible, so that re-reading the same stty settings for
the next command won't change anything.  That way, .inputrc wins
(persistently) over the original stty settings, but later changes to
stty settings still win over .inputrc.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash expr problem/bug... 0$val

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   #  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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

shared library installation

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: failure in pipeline not reflected in $?

[Paul Jarc]

[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
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: pipeline outlives TERMed bash

[Paul Jarc]

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, move logger
into a separate /service/foo/log/run script.
http://cr.yp.to/daemontools/faq/create.html#runlog>

For more help with daemontools, try [EMAIL PROTECTED] or
[EMAIL PROTECTED]


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: ansi escape sequences in prompt mess-up the command prompt

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: programmable auto completion with embedded ":" not working?

[Paul Jarc]

"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
COMP_WORDBREAKS.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: error in math args?

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: HERE document mystery

[Paul Jarc]

"Com MN PG P E B Consultant 3" <[EMAIL PROTECTED]> wrote:
> echo THIS DOES NOT WORK
> foo=$(cat exp_test < 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 also be entirely inside $().  Move the closing )
   after "BAD".
2. [0-9]* matches every line, since * matches 0 or more occurrences.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Can't get the set-user-id bit to work

[Paul Jarc]

Sebastian Tennant <[EMAIL PROTECTED]> wrote:
> I have a 3-line script; foo:

The setuid bit works only for binaries, not scripts.  This is a
limitation of the kernel, necessary for security.

> A cron.daily script handles mandb.  I elected to install it with the
> set-user-id bit set, as you can see:

Is it meant to be installed that way?  If not, you probably shouldn't
do that.  It might break something, or introduce a security risk.

> it certianly shouldn't have any trouble creating it in /tmp:
>
>   drwxrwxr-x  13 root root 4096 Dec 27 16:50 /tmp

With those permissions, only the root user and root group can create
files in /tmp.  To allow all users to create files there, make it
world-writable and sticky:
# chmod 1777 /tmp
# ls -ld /tmp
drwxrwxrwt  13 root root 4096 Dec 27 16:50 /tmp


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Can't get the set-user-id bit to work

[Paul Jarc]

Sebastian Tennant <[EMAIL PROTECTED]> wrote:
> OK, but mandb _is_ a member of the root group, so shouldn't it be able
> to write files in /tmp with the permissions as they stand?

No, you'd have to make it setuid to root, or setgid to the root
group.  The user/group associations in /etc/passwd and /etc/group
aren't involved.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: "echo: write error: Broken pipe" even when DONT_REPORT_SIGPIPE set

[Paul Jarc]

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
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Conditional expression problem: both "-a file" and "! -a file" return true

[Paul Jarc]

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 return failure for "test ! -a file"
> if file exists.  Bash got this wrong, so indeed it is a bug.

No, I think that quote only says that this:
  ! 1 -a 2
is the same as this:
  ( ! 1 ) -a 2
and not this:
  ! ( 1 -a 2 )

It doesn't give us any guidance for deciding whether ! is an operator
or operand in any particular case.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: can't expand after colon

[Paul Jarc]

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

Re: Possible bash bug when dealing with CR/LF in variable expansion

[Paul Jarc]

"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
return here.

> [EMAIL PROTECTED]:~/bash/bash-3.1$ echo $zak | od -t x1
> 000 0d 0a
> 002

echo adds a newline at the end of its output.  Even if zak had a
newline, since it's unquoted, that newline would be removed.

> [EMAIL PROTECTED]:~/bash/bash-3.1$ zak="${zak}karin"
> [EMAIL PROTECTED]:~/bash/bash-3.1$ echo $zak | od -t x1
> 000 0d 6b 61 72 69 6e 0a
> 007

Again, the newline comes from echo, not from zak.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: exit somtimes not exit's the script

[Paul Jarc]

[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
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: problem ? bug ?

[Paul Jarc]

[EMAIL PROTECTED] wrote:
> [kaneda<-ogorasek]~$if [ ! -a /etc/passwd ] ; then echo si ; fi

-a is used as a binary "and" operator here.  The expressions "!" and
"/etc/passwd" are nonempty strings, so both are considered true, and
the overall result is true.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: eval in functions in pipelines doesn't set variables globally

[Paul Jarc]

[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.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: BUG: ls -ld directory/

[Paul Jarc]

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
> slash in black.

You probably have ls aliased to 'ls -F', or some combination of
options that includes -F.  (Check with "alias ls".)  Read the
documentation for ls to see if there is a different combination of
options that gives you the behavior you want.  If you can't find it,
you can write to bug-coreutils@gnu.org to submit a feature request.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: trap handler scope wrong?

[Paul Jarc]

Phillip Susi <[EMAIL PROTECTED]> wrote:
> Chet Ramey wrote:
>> That's about right, but you need >&3 in the trap command.
>
> I did have > &3 in the trap command, see?

You have "> &3".  You need ">&3", without a space.

> I'm a bit worried though about hard coding the fd 3.  Is there a way
> to get the next available fd number and save it in a variable,
> rather than hard code 3?

Unfortunately, no.  You could use a higher number, which would be less
likely to be used, but if you want to be portable to other shells, you
can only go up to 9.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to suppress async messages for background jobs

[Paul Jarc]

Francesco Montorsi <[EMAIL PROTECTED]> wrote:
>   [EMAIL PROTECTED]:~$ kwrite &
> =>[1] 20986
>   [EMAIL PROTECTED]:~$
> =>[1]+  Donekwrite
>   [EMAIL PROTECTED]:~$
>
> is there a way to tell bash not to print those lines marked with => ?

If you don't need to refer to the process as %1, etc.:
$ ( kwrite & )

I have this in my .bashrc to I can use alt-Enter to run something in
the background without keeping track of it as a shell job:
bind $'Meta-RET: "\001(\005&)\r"'


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: document that echo can't be given a NULL

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Using variables in variables names

[Paul Jarc]

"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 work:
ac=12 eval "dings$ac=wasannersder"


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Using variables in variables names

[Paul Jarc]

"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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Question about variables and for loop

[Paul Jarc]

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 an option to
"set":
eval "set x $XXX"
shift


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Grouped pipeline clobbering question

[Paul Jarc]

Phillip Susi <[EMAIL PROTECTED]> wrote:
> cat file | ( head --lines=1 ; sed -e x )
>
> I thought that head should consume the first line from the pipe, leaving 
> the rest queued for sed to consume, but this does not seem to be the 
> case.

head may read an arbitrary amount of data from the pipe, although it
will print only as much as you tell it to.  To get the behavior you
want, you'll have to duplicate head's behavior in sed:

cat file | sed -e '1,10{p;d;}' -e x

And in this case, cat is unnecessary too:

sed -e '1,10{p;d;}' -e x < file


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash ignoring .inputrc (or am I dumb)

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: pattern matching: range expression

[Paul Jarc]

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Selinux bash prompt decorations

[Paul Jarc]

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 environment have an 
> easy way to see what the session is running at.

You can put the information in PS1 without bash having special
functionality for getting it.
selinux_user=`...`
PS1='$selinux_user...'


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: test -f with no args is true

[Paul Jarc]

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 shells behave, and what POSIX/SUS says they
should do.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

[Paul Jarc]

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 arithmetic expansion that did not occur within double  quotes
#   for word splitting.

> so if i quote ${foo} like so:
> $ gawk 'BEGIN {foo="'"${foo}"'"}'
> it'll work in this case, but then fail if foo contains newlines:
> foo="a
> b
> c"

What do you mean by "fail"?  What do you want to happen in this case?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

[Paul Jarc]

Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 04 May 2006 00:44, Paul Jarc wrote:
>> What do you mean by "fail"?  What do you want to happen in this case?
>
> i meant gawk hates it ... not bash

Ok, and what about the second question?  What are you trying to do
that you haven't figured out how to do?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Selinux bash prompt decorations

[Paul Jarc]

Steve Grubb <[EMAIL PROTECTED]> wrote:
> Its not poor practice to make something usable for people.
...
> For the moment, we are going the route of doing this via `id -Z`. But I 
> thought there was a common problem across secure distributions that we could 
> create a standard for. TSOL could link to its libraries, RHEL could link to 
> libselinux, etc.

Having a common interface to all of these libraries would be good.
But adding new mechanisms to other programs to use those libraries,
when they can just as easily get to the same functionality via
existing mechanisms like command substitution, is not good.
Interdependencies should be kept to a minimum, and pushed to as high a
level as possible.  Instead of modifying bash to call some
standardized get_security_role() function, put a standardized
`get-security-role` command in PS1.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to use [[ string =~ regexp ]]?

[Paul Jarc]

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
string, and "$" to anchor it to the end:
[[ string =~ ^[a-z]$ ]]


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: here document and STDIN

[Paul Jarc]

"Cai Qian" <[EMAIL PROTECTED]> wrote:
> For following code,
>
> sh <   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 here document, so
the next thing read from there will be end-of-file.  If you want the
"read" command to read from the original stdin that was present before
the here document was introduced, you can copy it to another
descriptor:

sh < So I can run some Perl code inside like,
>
> perl - <<'EOF'
>  X
>
> EOF

With perl, it may be easier to use -e instead of a here document:
perl -e '
X
'

Then perl will still be connected to the original stdin, without any
need for duplicating descriptors.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: here document and STDIN

[Paul Jarc]

I wrote:
> sh < read <&3
> EOF

Sorry, that first line should be:
sh 3<&0 

Re: here document and STDIN

[Paul Jarc]

"Cai Qian" <[EMAIL PROTECTED]> wrote:
> The information is helpful. The problem by using
>
> perl -e '
>X
> '
>
> is that there seems no way to using single quota in Perl code any more.

It's not very concise, but you can do this:

perl -e '
... '\'' ...
'

>From the shell's point of view, this is a single-quoted string,
adjacent to a backslash-escaped single quote, adjacent to another
single-quoted string.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: EOF does not work in echo

[Paul Jarc]

"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 the terminal.  Control-D is also used
in other contexts (such as typing at a terminal in "raw" mode) to
produce the character 004.

In the case of a pipe, a reader will not see EOF until all writers
have closed the pipe (typically when they exit).


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Aliases fail in command substitution in noninteractive mode.

[Paul Jarc]

[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 option is set using shopt (see the description of
   shopt under SHELL BUILTIN COMMANDS below).


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash expansion nuance or bug?

[Paul Jarc]

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 the alias value is a blank, then the next
# command word following the alias is also checked for alias
# expansion.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: while do done has problems with global variables

[Paul Jarc]

[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

Re: terminating lines with accidental eof

[Paul Jarc]

[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 won't affect
your situation, since you only have EOF, not an error.

> Linking /bin/sh to /bin/bash does NOT maintain the bourne shell API.

This is well known.  I don't think Bob was recommending that you do
that.  He was just pointing out that many systems do it, and so your
statement of what /bin/sh does was ambiguous since you had not
specified which /bin/sh you're using.

> command history browsing must, similarly, present "commented"
> commands in case thay are executed as a result of this issue.

Has anyone verified that this happens for history browsing?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: automatic code generation

[Paul Jarc]

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 < output-file


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Python and Bash

[Paul Jarc]

"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.  python will
process SIGINT by throwing a KeyboardInterrupt exception.  Have you
checked to see how that exception is handled in your script?  If it's
begin caught and ignored, that's the best place to fix it.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: !* goofs here-strings

[Paul Jarc]

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
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: null command and parameter expansion for "Display error if null or unset"

[Paul Jarc]

"Dave Rutherford" <[EMAIL PROTECTED]> wrote:
> On 7/31/06, Poor Yorick <[EMAIL PROTECTED]> wrote:
>> : ${FAKEVAR?} || echo hello
>
> Try this and then run your script:
>
> export FAKEVAR="echo This could have been rm -rf $HOME"

That won't do anything.  The contents of $FAKEVAR, if any, are just
passed as arguments to :, which does nothing.  Since the expansion
isn't quoted, word splitting and pathname expansion are applied -
that's extra useless work, but not harmful.


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"

[Paul Jarc]

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

Re: unable to capture return value using backticks and local

[Paul Jarc]

"Adam Monsen" <[EMAIL PROTECTED]> wrote:
> foo()
> {
>local TICKED=`false`
>echo RV: $?
> }
>
> foo
> # prints "RV: 0", but I would expect "RV: 1"

You get 0 here because that's the status from the "local" command.  To
get the status from a backtick command, you need the assignment to be
alone, not part of another command:
foo()
{
  local TICKED
  TICKED=`false`
  echo RV: $?
}


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bug with 'test' built-in.

[Paul Jarc]

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.

[Paul Jarc]

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: Espace characters need -e, wrong behaviour

[Paul Jarc]

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

[Paul Jarc]

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: functions and set -e

[Paul Jarc]

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

[Paul Jarc]

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: incorrect brace expansion when using default values

[Paul Jarc]

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: completion inconsistencies involving symlinks

[Paul Jarc]

"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: completion hosed by :

[Paul Jarc]

"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?

[Paul Jarc]

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

[Paul Jarc]

"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: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly

[Paul Jarc]

Vasily Tarasov <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] $ myfunc
> Press tab once:
> [EMAIL PROTECTED] $ myfunc qwe:o
> Press tab secondary:
> [EMAIL PROTECTED] $ myfunc qwe:qwe:o

You can work around this by removing : from $COMP_WORDBREAKS.  Ii
looks like a bug, since 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://lists.gnu.org/mailman/listinfo/bug-bash

Re: ...Limitation?

[Paul Jarc]

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 3>&1 && status=`exec 4>&1 && { 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

[Paul Jarc]

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

[Paul Jarc]

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 

>cword<
><
>words<
>myfunc<
><
>reply<
>qwe:on<
>qwe:off<

$ myfunc qwe:o

>cword<
>qwe:o<
>words<
>myfunc<
>qwe:o<
>reply<
>qwe:on<
>qwe:off<

$ 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

Re: no parameter expansion and no special meaning to control operator

[Paul Jarc]

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: How to detect bash?

[Paul Jarc]

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

[Paul Jarc]

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: botched configure check for /dev/stdin

[Paul Jarc]

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: Why is this executed inside a subshell?

[Paul Jarc]

"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: mkfifo and tee within a function

[Paul Jarc]

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 < $> 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: Quotes problem ?

[Paul Jarc]

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_number"p" /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_number"p /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: Quotes problem ?

[Paul Jarc]

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: long lines not wrapping correctly in Mac OS X

[Paul Jarc]

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: man page "-c" explanation clarity

[Paul Jarc]

"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: can't pass a response from bash script to an app's interactive dialog

[Paul Jarc]

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: reading the first colums of text file

[Paul Jarc]

"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: Just created alias doesn't work in a string of commands

[Paul Jarc]

"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: /etc/bash.bashrc derivation and "misuses"

[Paul Jarc]

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: while read subcommand problem

[Paul Jarc]

rleeden <[EMAIL PROTECTED]> wrote:
> NOTE: This is just an example, so I don't need alternatives for how I could
> achieve the specifics shown above. I need to find a good solution where I
> can do things with a file (whether it be with sed, awk, tail, head etc.)
> then pipe 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 ...; do var=...; done; use "$var"; }


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: while read subcommand problem

[Paul Jarc]

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 would be applied
to your while loop instead.  For example:

while ...; do var=...; done 

Re: while read subcommand problem

[Paul Jarc]

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
> 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: parameter expansion malinterpretation

[Paul Jarc]

[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: Syntax question

[Paul Jarc]

"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: shouldn't prompt printing be smarter?

[Paul Jarc]

Francesco Montorsi <[EMAIL PROTECTED]> wrote:
> why would you ever want to have the prompt printed at non-zero column of 
> the terminal?

One possible reason: so you can know whether the previous command
ended its output with a newline.  Otherwise the output becomes
slightly ambiguous.

>> If you want the shell to always add an extra newline then you can
>> always add one to your PS1 setting.
>
> unfortunately in that way I suppose the terminal would then show:
>
> [EMAIL PROTECTED]:~$ echo hello world
> hello world
>
> [EMAIL PROTECTED]:~$

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

Re: Problem with array element assignment

[Paul Jarc]

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: Bash arithmetic doesn't give error message on wrap.

[Paul Jarc]

[EMAIL PROTECTED] (Bob Proulx) wrote:
> On some cpus the result is done one way and on others the result is
> done a different way.  It is in these cases where typically POSIX
> would give up and declare it undefined behavior.

Yes, and those are exactly the cases where a message would be helpful,
to let the user know that the result is not portable, and does not
necessarily indicate what the user thinks it does.

Undefined behavior makes sense for C, since C is essentially a
"portable assembly language".  For a higher-level language, it makes
considerably less sense.  And in any case, it does not require the
implementation to be unhelpful.

> About the only way for bash to avoid it would be to include a full
> arbitrary precision math library to evaluate these expressions
> itself.

It depends on the goal.  If the goal is to produce a mathematically
correct 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

Re: Bash arithmetic doesn't give error message on wrap.

[Paul Jarc]

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.

[Paul Jarc]

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: How to remove a specific line in a file

[Paul Jarc]

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-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Characters aren't being properly escaped/evaluated in a Bash

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   The problem is that if I did this out of the box
>   like the following, it 'flattens' the list:
>
>   Example:
>   for j in `cat $i`; do
>   echo $j
>   done
>
>   Output:
>   This
>   is
>   a
>   file
>   [...]

Inserting quotes into the output of the command substitution won't
help.  Quotes are given special syntactic status only if they are
unquoted themselves, and do not appear as the result of any kind of
expansion.

You can use a "while read" loop as Chet suggested, or you can tell
bash to split the `cat` expansion only at newlines, not as other
whitespace:
  old_ifs=$IFS
  IFS=$'\n'
  for j in `cat "$i"`; do
...
  done
  IFS=$old_ifs

If you have other unquoted expansions within the body of the for loop
that should use the normal IFS for splitting, then you'll have to
restore the original IFS after splitting `cat`, but before entering the
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

Re: read 1 var in when executing command

[Paul Jarc]

jdh239 <[EMAIL PROTECTED]> wrote:
> I would prefer, again, just to execute the command with the domain name
> following  Not sure how to do it.

You can define the command as a shell function (see "Shell Function
Definitions" in the man page under "SHELL GRAMMAR").  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

Re: Generating unique file names

[Paul Jarc]

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: backwards menu-complete with shift+tab

[Paul Jarc]

<[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: Infinite loop and crash Linux via BASH command

[Paul Jarc]

[EMAIL PROTECTED] wrote:
> I don't know by this means (perhaps anybody here with bigger  
> experiences to can explain us) this simple command creates a job in  
> background and in loop that quickly consome all the processing.

Yes, because that's exactly what you're telling bash to do, if you run
that command.  If you don't want bash to do that, don't tell it to.
This isn't a bug.  It's just an example of the fact that any
sufficiently powerful language will be able to express things you
don't want to do.  If the language were too limited to 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

Re: set function and special builtin set

[Paul Jarc]

Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> Andreas Schwab wrote:
>>:
>>
>> If a simple command results in a command name and an optional
>> list of arguments, [...]
>
> 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

Re: Timing an operation

[Paul Jarc]

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: Pattern replacement inconsistency

[Paul Jarc]

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: tracing inside functions

[Paul Jarc]

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 without editing the script.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: variable lost when while loop piped

[Paul Jarc]

[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: Bash command completion when not connected to a terminal

[Paul Jarc]

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: wrong logical evaluation of expressions involving true or false commands

[Paul Jarc]

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