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.
Chet Ramey wrote:
> Here's the deal. Only single quotes and backslashes quote the history
> expansion character. Double quotes don't matter ...
Then why do they cause a difference in behaviour?
> Since ! is not one of the characters for which Posix says the backslash
> will act as an escape, t
Lawrence D'Oliveiro wrote:
Chet Ramey wrote:
Chet Ramey wrote:
Yes, this is where the semantics of history expansion clash with traditional
shell behavior. Only single quotes inhibit history expansion.
In that case, situation number 3 is producing the wrong result, since there
are no single
Chet Ramey wrote:
>> Chet Ramey wrote:
>>
>>> Yes, this is where the semantics of history expansion clash with traditional
>>> shell behavior. Only single quotes inhibit history expansion.
>>
>> In that case, situation number 3 is producing the wrong result, since there
>> are no single quotes t
> | Was written by me:
> Was replied by Eric Blake:
> | "SHELL The full pathname to the shell is kept in this environment variable.
> | If it is not set when the shell starts,
> | Bash assigns to it the full pathname of the current user's login shell."
> |
> | SHELL is not being exported to the e
Lawrence D'Oliveiro wrote:
Chet Ramey wrote:
Yes, this is where the semantics of history expansion clash with traditional
shell behavior. Only single quotes inhibit history expansion.
In that case, situation number 3 is producing the wrong result, since there
are no single quotes there, only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pedro Izecksohn on 7/17/2008 9:55 PM:
| "SHELL The full pathname to the shell is kept in this environment variable.
| If it is not set when the shell starts,
| Bash assigns to it the full pathname of the current user's login shell."
|
|
"SHELL The full pathname to the shell is kept in this environment variable.
If it is not set when the shell starts,
Bash assigns to it the full pathname of the current user's login shell."
SHELL is not being exported to the environment on Cygwin.
For reference:
http://cygwin.com/ml/cygwin/20
Hi,
I've got a shell script for installing a binary. In this script I set the
binary to mode 4755. When I 'ls' the binary from within the shell script I
see that it has the setuid bit set. When I exit the shell script, the binary
is no longer setuid.
I can setuid the binary from outside the she
Chet Ramey wrote:
> Yes, this is where the semantics of history expansion clash with traditional
> shell behavior. Only single quotes inhibit history expansion.
In that case, situation number 3 is producing the wrong result, since there
are no single quotes there, only a backslash.
Whichever way
LynnOS wrote:
Thanks ,but after I export PWD,the problem doesn't go
As I explained previously, this is not a bash problem. This is a
problem with file permissions in the current working directory.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[
Thanks ,but after I export PWD,the problem doesn't go
the following is my step:
[EMAIL PROTECTED]:~# export
declare -x EDITOR="/bin/vi"
declare -x HOME="/root"
declare -x LD_LIBRARY_PATH="/usr/lib:/lib"
declare -x LOGNAME="root"
declare -x MAIL="/var/mail/root"
declare -x OLDPWD
declare -x OPIEDI
To get rid of null elements in an array, I currently do something like this:
bash-3.2$ var1=("with spaces" "more spaces" '' "the end")
bash-3.2$ for v in "[EMAIL PROTECTED]"; do if test "$v"; then var2+=("$v");
fi; done
bash-3.2$ echo [EMAIL PROTECTED]
3
bash-3.2$ printf '%s\
> > If you want fully sh-compatible behavior, you have to turn off history
> > expansion (set +o history).
>
>I find it adequate to set histchars to an empty string.
Sorry, you turn off history expansion with `set +o histexpand'. You don't
need to turn off history entirely.
Chet
--
``The
> *"You might be able to avoid the need for the getcwd call at startup by
> exporting PWD*"
>
> Sorry,would you give us more details about how to avoid the "error" message
export PWD
Bash performs a check at startup in which it compares $PWD to `.' and skips
the call to getcwd if the two refer t
I have found small bug in patch number 035. There aren't 3 lines after
the change, so patch with fuzz=0 don't work. I'm sending changed patch.
Can you please change official patch?
BASH PATCH REPORT
=
Bash-Release: 3.2
Pat
16 matches
Mail list logo
