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
> *"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
> > 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
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\
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
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[
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
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
"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
-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."
|
|
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
> | 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
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
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:
> 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
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.
16 matches
Mail list logo
