Hello Lawrence!
Am Fri, 30 May 2025 04:53:06 -0400 schrieb Lawrence Velázquez :
> Your example commands demonstrate something else. The command
>
> PATH=~/foo:~/bar
>
> has always assigned a value like '/myhome/foo:/myhome/bar', POSIX
> mode or not. This
On Fri, May 30, 2025, at 3:36 AM, Martin Schulte wrote:
> https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says:
>
> 19. Literal tildes that appear as the first character in elements of
> the PATH variable are not expanded as described above under Tilde
> Expansi
Le 30/05/2025 à 09:36, Martin Schulte écrivait :
Hello,
https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says:
19. Literal tildes that appear as the first character in elements of the PATH
variable are not expanded as described above under Tilde Expansion.
Is this no longer
Hello,
https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says:
19. Literal tildes that appear as the first character in elements of the PATH
variable are not expanded as described above under Tilde Expansion.
Is this no longer true from version 5.2 on?
$ bash--posix
On Tue, 4 Feb 2025 at 11:03, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> To address the above points, the following text (or similar language) is
> proposed for inclusion in the Bash Reference Manual:
>
> *[...] *
In interactive Bash sessions, any element
On 2/3/25 8:03 PM, Zeffie via Bug reports for the GNU Bourne Again SHell wrote:
To whom it may concern,
Bash has long maintained a legacy feature whereby, in interactive sessions,
a literal tilde (`~`) at the start of a `PATH` element (e.g., `~/bin`) is
expanded to the user’s home directory
ah , this might be due to u use it after a bash keyword
1. it doesnt need export cause its already exported
2. if u wanna export , export it
but 3. do PATH='...' or ".." ur string
but not after export or declare
just on its own line
greets
On Tue, Feb 4, 2025, 4:53 AM Zeffi
sion
by ur code examples
.. in quotes , ~ doesnt expand
This demonstration confirms that in Bash, an unquoted tilde (e.g. ~) in
a variable assignment is immediately expanded to the full home
directory—this happens consistently whether Bash is running normally, as
sh, or in POSIX mode. However,
doesnt expand
greets
On Tue, Feb 4, 2025, 2:04 AM Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> To whom it may concern,
>
> Bash has long maintained a legacy feature whereby, in interactive
> sessions, a literal tilde (`~`) at the start of a `PATH` element (e.g.,
To whom it may concern,
Bash has long maintained a legacy feature whereby, in interactive
sessions, a literal tilde (`~`) at the start of a `PATH` element (e.g.,
`~/bin`) is expanded to the user’s home directory at the time a command
is executed. While this behavior can sometimes “help” users
On Mon, Feb 3, 2025, at 2:57 PM, dale.wor...@comcast.net wrote:
> Within that context, if an element of PATH contains a '~' character, you
> don't expect that to cause execution requests to look in your home
> directory, because '~' isn't the name of your h
Subject: Re: Tilde is expanded in $PATH, inconsistent behavior
Date: Mon, 27 Jan 2025 15:21:06 -0500
Keith Thompson writes:
> The "Tilde Expansion" section of the bash manual does talk about
> using '~' when setting $PATH, but that applies only when setting
On Fri 2025-01-24 11:45:22 EST, Chet Ramey wrote:
> On 1/23/25 9:15 PM, Keith Thompson wrote:
>
> > But I don't see anything in the "Tilde Expansion" section that
> > documents the behavior of a literal '~' in $PATH.
>
> It remains undocumented.
T
On 1/23/25 9:15 PM, Keith Thompson wrote:
But I don't see anything in the "Tilde Expansion" section that
documents the behavior of a literal '~' in $PATH.
It remains undocumented.
I suggest it would be better to document the behavior, since I imagine
it
On 1/23/25 6:37 PM, Keith Thompson wrote:
Bash Version: 5.2
Patch Level: 32
Release Status: release
Description:
A literal '~' or other tilde-prefix at the beginning of an
element of $PATH is expanded when a command is executed
from the bash prompt. This is undocu
On Thu, Jan 23, 2025 at 18:15:38 -0800, Keith Thompson wrote:
> $[...] appears to behave like $((...)). Is it equivalent?
It was the proposed syntax for arithmetic in a POSIX draft a couple
decades ago. Bash implemented it, and it started to catch on. But
then POSIX went with $(( )) instead. $
On Thu, Jan 23, 2025 at 5:31 PM Lawrence Velázquez wrote:
>
> On Thu, Jan 23, 2025, at 6:37 PM, Keith Thompson wrote:
> > Description:
> > A literal '~' or other tilde-prefix at the beginning of an
> > element of $PATH is expanded when a command is exe
Description:
A literal ~ or other tilde-prefix at the beginning of an
element of $PATH is expanded when a command is executed
from the bash prompt. This is undocumented and inconsistent with
the behavior of other commands that can execute commands.
This expansion
On Thu, Jan 23, 2025, at 6:37 PM, Keith Thompson wrote:
> Description:
> A literal '~' or other tilde-prefix at the beginning of an
> element of $PATH is expanded when a command is executed
> from the bash prompt. This is undocumented and inconsistent with
>
Description:
A literal '~' or other tilde-prefix at the beginning of an
element of $PATH is expanded when a command is executed
from the bash prompt. This is undocumented and inconsistent with
the behavior of other commands that can execute commands.
This expansion doesn
).
>
> If you don't want to use BASH_SOURCE_PATH, don't set BASH_SOURCE_PATH,
> and unset it explicitly if you want to be sure.
>
> > `BASH_SOURCE_PATH=' could just mean
> > the current working directory skipping steps 1 and 2.
>
> That is consistent with other PATH-like variables.
I now agree.
On 5/14/24 10:24 PM, Matheus Afonso Martins Moreira wrote:
preparation for a v3 patch set
I'm thinking it won't be needed. I just fetched the latest commits
and there's already code implementing BASH_SOURCE_PATH.
I guess there isn't any point in submitting a new patch set
without the other refa
ter a colon-separated list of directories,
not the name of the PATH-like variable that string is bound to.
Passing the value allows the caller to determine how to treat specific
values. For instance, if we wanted to handle a NULL value differently
than, say, _find_user_command_internal(), the calle
URCE_PATH,
and unset it explicitly if you want to be sure.
`BASH_SOURCE_PATH=' could just mean
the current working directory skipping steps 1 and 2.
That is consistent with other PATH-like variables.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
> preparation for a v3 patch set
I'm thinking it won't be needed. I just fetched the latest commits
and there's already code implementing BASH_SOURCE_PATH.
I guess there isn't any point in submitting a new patch set
without the other refactoring work I've done.
If I can contribute in any other wa
> Anyway, there isn't any real reason to modify findcmd.c.
> Everything this needs is already available.
OK, I will remove it.
-- Matheus
> This isn't needed given the existence of find_in_path().
OK. I will remove it in preparation for a v3 patch set.
-- Matheus
m Chet Ramey, the maintainer.
I am paying attention to his emails.
For example, this email factored heavily into my choices:
https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00116.html
> it should be implemented using a call to find_in_path()
> with the appropriate path string and f
2024年5月14日(火) 12:32 Matheus Afonso Martins Moreira :
> > The patches touch the interface of many functions
>
> I added one external function: find_in_path_var.
> The other changes are all static and local.
>
> > It seems essentially equivalent to just calling
> > find_in_path (list->word->word,
it first so I left it in.
>
> Searching the current directory is the existing behavior (albeit when using
> PATH) when not in posix mode.
I agree that we should fall back to the files in the current working
directory for `source name'. However, in the above, I was talking
about the behavior of the suggested option to turn off the fallback.
27;
and `unset -v BASH_SOURCE_PATH'.
> That's the standard behavior of PATH-like
> variables: a null element anywhere is equivalent to `.'. Does this
> require a special case?
I see. I was assuming that users who want to completely turn off the
new feature would set an empty
or (albeit when using
PATH) when not in posix mode.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
On 5/13/24 11:32 PM, Matheus Afonso Martins Moreira wrote:
The patches touch the interface of many functions
I added one external function: find_in_path_var.
The other changes are all static and local.
It seems essentially equivalent to just calling
find_in_path (list->word->word, path_v
On 5/13/24 7:47 PM, Koichi Murase wrote:
2024年5月13日(月) 19:38 Matheus Afonso Martins Moreira
:
The PATH variable is hard coded in the user command finder function.
Transforming it into an argument allows reusing the file finding logic
with variables other than PATH, making the code more flexible
to local files.
You can do this by temporarily turning off source_searches_cwd if
BASH_SOURCE_PATH is set.
In that case,
we need to make sure that `find_in_path_var()' returns NULL in the
case of empty BASH_SOURCE_PATH.
Do you mean BASH_SOURCE_PATH= ? That's the standard behavior of PA
On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote:
The PATH variable is hard coded in the user command finder function.
Transforming it into an argument allows reusing the file finding logic
with variables other than PATH, making the code more flexible.
This isn't needed give
> The patches touch the interface of many functions
I added one external function: find_in_path_var.
The other changes are all static and local.
> It seems essentially equivalent to just calling
> find_in_path (list->word->word, path_value ("BASH_SOURCE_PATH", 1),
> FS_READABLE);
It is. I'm
> I think we should restrict the search in
> BASH_SOURCE_PATH and shouldn't fall back to local files.
I concur but thought it'd be wise to discuss it first so I left it in.
Users might expect it to respect the configuration option.
I also saw that many of the PATH-like variable
2024年5月13日(月) 19:38 Matheus Afonso Martins Moreira
:
> The PATH variable is hard coded in the user command finder function.
> Transforming it into an argument allows reusing the file finding logic
> with variables other than PATH, making the code more flexible.
I think what was suggeste
2024年5月13日(月) 19:40 Matheus Afonso Martins Moreira
:
> diff --git a/builtins/source.def b/builtins/source.def
> index 26040e70..7f870bfe 100644
> --- a/builtins/source.def
> +++ b/builtins/source.def
> @@ -177,6 +178,27 @@ search_for_file (WORD_LIST *list)
> [...]
> +static char *
> +isolated_searc
*);
static char *search_for_file (WORD_LIST *);
+static char *isolated_search_for_file (WORD_LIST *);
/* If non-zero, `.' uses $PATH to look up the script to be sourced. */
int source_uses_path = 1;
@@ -177,6 +178,27 @@ search_for_file (WORD_LIST *list)
return (filename);
}
+static
The PATH variable is hard coded in the user command finder function.
Transforming it into an argument allows reusing the file finding logic
with variables other than PATH, making the code more flexible.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 25
> No, it should be implemented using a call to find_in_path() with the
> appropriate path string and flags.
>
> I feel like a feature like BASH_SOURCE_PATH should take less than a
> dozen lines of code in source_builtin().
I agree. My version took more because I like splitt
On 5/7/24 6:35 AM, Koichi Murase wrote:
For consistency, shouldn't the suggested
feature to change the search path for the script files be implemented
by a similar flag CMDSRCH_XXX?
No, it should be implemented using a call to find_in_path() with the
appropriate path string and flags.
I
2024年5月5日(日) 18:56 Matheus Afonso Martins Moreira
:
> The PATH variable is hard coded in the user command finder function.
> Transforming it into an argument allows reusing the file finding logic
> with variables other than PATH, making the code more flexible.
There is already a ver
The PATH variable is hard coded in the user command finder function.
Transforming it into an argument allows reusing the file finding logic
with variables other than PATH, making the code more flexible.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 25
The PATH variable is hard coded in the user command finder function.
Transforming it into an argument allows reusing the file finding logic
with variables other than PATH, making the code more flexible.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 25
Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-bash@gnu.org
On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton wrote:
Bash executable completion doesn't work if there is a space in the
executable path.
This issue is still partially present in current version of
What do you
think 'source' does?
For the record:
unicorn:~$ help source
source: source filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the direc
On 1/26/24 8:28 AM, Ricky Tigg wrote:
Hopefully, my interpretation of the 'source' command is correct.
It's not: the `source' command reads and executes commands from the
filename argument. What do you think it does, and why do you think
the results you expected are correct?
--
``The lyf so s
On Fri, Jan 26, 2024, 14:29 Ricky Tigg wrote:
> BASH version: 5.2.26(1)-release. OS: Fedora; Desktop edition.
>
> Hello.
>
> Current state: Vim set as default text editor.
>
> $ cat .bashrc | grep '^export EDITOR'
> export EDITOR='/usr/bin/vim'
> $ typeset -p EDITOR
> declare -x EDITOR="/usr/bin/
BASH version: 5.2.26(1)-release. OS: Fedora; Desktop edition.
Hello.
Current state: Vim set as default text editor.
$ cat .bashrc | grep '^export EDITOR'
export EDITOR='/usr/bin/vim'
$ typeset -p EDITOR
declare -x EDITOR="/usr/bin/vim"
$ which nano
/usr/bin/nano
Failure: attempt to set a text e
On 7/5/23 6:36 AM, Sebastian Carlos wrote:
Hello,
I noticed that there's no mention in the manual that, when the PATH changes,
"hash -r" is run. I think that would be a nice addition, possibly on "4.1
Bourne Shell Builtins / hash"
Thanks; good catch.
--
``The lyf so
Hello,
I noticed that there's no mention in the manual that, when the PATH changes,
"hash -r" is run. I think that would be a nice addition, possibly on "4.1
Bourne Shell Builtins / hash"
Thanks.
On 3/9/23 5:42 PM, Moshe Looks wrote:
Thank you this is very illuminating and makes it clear that my naive
one-line fix would be inappropriate. Given the current state of
affairs there is really no good reason for PATH to ever be unset or
set to empty vs. explicitly set to '.', right
On 3/8/23 1:33 PM, Moshe Looks wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
When PATH is empty, the command_not_found_handle function is not
called when a command is not found.
I agree that bash should do a path search in the current directory when
PATH is
Thank you this is very illuminating and makes it clear that my naive
one-line fix would be inappropriate. Given the current state of
affairs there is really no good reason for PATH to ever be unset or
set to empty vs. explicitly set to '.', right? So might be worth
spelling out in the
Date:Thu, 09 Mar 2023 09:26:18 +0100
From:Andreas Schwab
Message-ID:
| But an unset PATH is *not* the same as PATH=.
That might be true, but POSIX says:
If PATH is unset or is set to null, or if a path prefix in PATH
contains a character
On Mär 08 2023, Grisha Levit wrote:
> I think it might make sense to change code that looks at the value of
> PATH to explicitly treat an empty value as `.' so that all such
> behavior is consistent.
But an unset PATH is *not* the same as PATH=.
--
Andreas Schwab, SUSE Labs, sch.
On Wed, Mar 8, 2023 at 4:28 PM Moshe Looks wrote:
> This is very old code and I have no idea what the original intention
> was in returning 'name' here or if doing so is still performing useful
> work, but the tests pass at least.
A null $PATH component is treated as the cur
-generic #74-Ubuntu SMP Wed Feb 22
14:14:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
When PATH is empty, the command_not_found_handle function is not
called when a command is not found.
Repeat-By
Ah that's it. That totally makes sense in retrospect, this is because I'm
basically sourcing the `set -a` so the second time it's set, but also the first
time `env` doesn't see the local.
(2) is what I was trying to achieve.
Thanks! Sorry for the noise.
Brian
> On Jul 27, 2021, at 6:37 PM, G
On Tue, Jul 27, 2021 at 11:42:02PM +, Van Klaveren, Brian N. wrote:
> [bash-test@227f958499c1 ~]$ cat sourceme
> #!/bin/bash
> FOO=bar
> FOO=bar2
> set -a
> env | grep FOO
You probably want to put set -a at the top, before the variables are
set. The -a flag isn't retroactive. It only applies
output: Linux 339aad08626d 5.10.25-linuxkit #1 SMP Tue Mar 23 09:27:39
UTC 2021 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
Sourcing a script with `set -a` at the end fails and an absolute path fails to
set variables
On 5/12/21 1:34 AM, Boleyn Su wrote:
Please refer to the subject.
To wrap the discussion, this appears to be a docker-container-only problem
and the result of a bug in glibc.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrat
good luck and wishes :)
On Wed, May 12, 2021, 13:30 Boleyn Su wrote:
> Totally agree. The OS is a customized one shipping a very old dockerd and
> I am in no position to avoid using it. In fact, this is the very reason I
> am using a Fedora container on top of it.
>
> Sent from https://boleyn.su
Totally agree. The OS is a customized one shipping a very old dockerd and I
am in no position to avoid using it. In fact, this is the very reason I am
using a Fedora container on top of it.
Sent from https://boleyn.su/phone
On Wed, May 12, 2021, 19:19 Boleyn Su wrote:
> For running it on an arm
I do not know how to run it on an Android phone either. BTW, I have fixed
my issue by updating dockerd to v20.10.6 following the suggestion in the
redhat bug tracker.
Sent from https://boleyn.su/phone
On Wed, May 12, 2021, 19:05 Alex fxmbsw7 Ratchev wrote:
> do you have instructions how to run
yea well i can only suggest using only newest versions, lower is nonsense
On Wed, May 12, 2021, 13:15 Boleyn Su wrote:
> I do not know how to run it on an Android phone either. BTW, I have fixed
> my issue by updating dockerd to v20.10.6 following the suggestion in the
> redhat bug tracker.
>
>
do you have instructions how to run the container
i have an a64 phone i wanted to try with termux ( and debian inside ) but i
dunno to spawn proot yet over the image, i think cause android fault chroot
is not enuff.. but ill try soon
On Wed, May 12, 2021, 11:58 Boleyn Su wrote:
> I just found so
I just found someone facing the same issuse
https://bugzilla.redhat.com/show_bug.cgi?id=1900021
On Wed, May 12, 2021, 17:25 Boleyn Su wrote:
> I tested that it is the container image to blame by compiling the source
> code from both the host and the container and checking that it only breaks
> i
I tested that it is the container image to blame by compiling the source
code from both the host and the container and checking that it only breaks
in the container. Maybe it is a libc bug or something. I will file a bug to
Fedora later. Would be great if anyone can test the image. Note that the
x8
On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote:
> Sorry, it is test -x instead of set -x. There are similar results for test
> - r file, [ -r file] and so on.
If "[ -r file]" is your code, then it fails because the "[" utility
needs "]" as its last argument, and you are giving it "file]
i may can check it out later but dont count on it
On Wed, May 12, 2021, 10:53 Boleyn Su wrote:
> I know it is supposed to always work but it do break here. If anyone can
> reproduce it would be more convincing though. I am using the Fedora 34
> container image from
> https://dl.fedoraproject.org
I know it is supposed to always work but it do break here. If anyone can
reproduce it would be more convincing though. I am using the Fedora 34
container image from
https://dl.fedoraproject.org/pub/fedora/linux/releases/34/Container/aarch64/images/Fedora-Container-Base-34-1.2.aarch64.tar.xz
On Wed
i dunno but, -x is for exe flag and -r for readable, and it never did not
work
On Wed, May 12, 2021, 10:32 Boleyn Su wrote:
> Sorry, it is test -x instead of set -x. There are similar results for test
> - r file, [ -r file] and so on.
>
> On Wed, May 12, 2021, 13:34 Boleyn Su wrote:
>
> > Pleas
Sorry, it is test -x instead of set -x. There are similar results for test
- r file, [ -r file] and so on.
On Wed, May 12, 2021, 13:34 Boleyn Su wrote:
> Please refer to the subject.
>
Please refer to the subject.
On 1/14/21 5:15 AM, Robert Elz wrote:
I suspect what you're being confused by, is that the "searches for" is
typically done (in shells, I have no idea what the code inside bash is
like) by simply taking each element of PATH, appending "/command_name"
and attempting an
I give up trying to quote appropriate context. Here's what bash 5.0
is doing:
unicorn:~$ echo "$PATH"
/home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
unicorn:~$ type moo
bash: type: moo: not found
unicorn:~$ echo "echo M" &
Date:Wed, 13 Jan 2021 21:45:08 -0500
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87im806xu3@hobgoblin.ariadne.com>
| Of course, as described in the manual page, Bash first searches for an
| executable with the right name in the PATH, and t
> On 2021/01/09 23:52, n952162 wrote:
>> I consider it a bug that bash (and its hash functionality) includes
>> non-executable files in its execution look-up
Of course, as described in the manual page, Bash first searches for an
executable with the right name in the PATH, and the
On 2021/01/09 23:52, n952162 wrote:
Hello,
I consider it a bug that bash (and its hash functionality) includes
non-executable files in its execution look-up
But bash doesn't have an execution lookup.
It has a PATH lookup, and a completion lookup (for executables
when appropriate), bu
table.
Perhaps it's there to support PATH look up for arguments to the bash
command. That would also be a bug. Why should it be okay to execute
a
non-executable script? Supporting users who are too lazy to chmod a
file ought to be less important than supporting users who want
fine-grain control o
> Perhaps it's there to support PATH look up for arguments to the bash
> command. That would also be a bug. Why should it be okay to execute
> a
> non-executable script? Supporting users who are too lazy to chmod a
> file ought to be less important than supporting users who want
Hello,
I consider it a bug that bash (and its hash functionality) includes
non-executable files in its execution look-up and then (inevitably)
simply reports an error, because its such files aren't executable.
Perhaps it's there to support PATH look up for arguments to the bash
comm
On 4/18/19 11:32 AM, Thomas Deutschmann wrote:
> Actual result:
> ==
> bash-test.sh: line 5: bar=${${foo}_blah}: bad substitution
> Rest of the script
>
>
> Expected result:
>
> bash-test.sh: line 5: bar=${${foo}_blah}: bad substitution
> I run after the failing_func
Hi,
Test script:
#!/bin/bash
failing_function() {
local foo=${1}
# force bad substitution
local bar=${${foo}_blah}
echo "You will never see this text!"
}
if [[ 1 -eq 1 ]]
then
# Current code path
failing_function
echo "I run after the f
On Fri, Mar 08, 2019 at 09:53:39AM -0500, Chet Ramey wrote:
> On 3/7/19 9:42 AM, Dr. Werner Fink wrote:
>
> >> There is a slightly updated version of that patch attached to this message.
> >
> > OK ... the hidden directories do work now ... but in the test suite
> > of sed the test case sed-4.7/t
On 3/7/19 9:42 AM, Dr. Werner Fink wrote:
>> There is a slightly updated version of that patch attached to this message.
>
> OK ... the hidden directories do work now ... but in the test suite
> of sed the test case sed-4.7/testsuite/subst-mb-incomplete.sh with
>
> print_ver_ sed
>
> require_
; > >
> > > Description:
> > > Since patch bash50-001 there is a regession on path expansion.
> > > The script example below shows:
> > >
> > > bash/bash> bash tmp/bug.sh
> > > 5.0.2(1)-release
> > > drwx
On Mon, Mar 04, 2019 at 09:00:38AM -0500, Chet Ramey wrote:
> On 3/4/19 8:19 AM, wer...@suse.de wrote:
>
> > Bash Version: 5.0
> > Patch Level: 2
> > Release Status: release
> >
> > Description:
> > Since patch bash50-001 there is a regession on path
On 3/4/19 8:19 AM, wer...@suse.de wrote:
> Bash Version: 5.0
> Patch Level: 2
> Release Status: release
>
> Description:
> Since patch bash50-001 there is a regession on path expansion.
> The script example below shows:
>
> bash/bash> b
-default #1 SMP Tue Feb 12
14:01:48 UTC 2019 (268f014) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 5.0
Patch Level: 2
Release Status: release
Description:
Since patch bash50-001 there is a regession on path expansion.
The script example below
On Sun, Dec 30, 2018 at 10:10:42PM +0100, Dušan Kreheľ wrote:
> Hello.
>
> If I try in bash this command ex. "rmdir somethingA > somethingA.out
> 2>&1" work right. But, if I try "rmdir somethingB 2>&1 >
> somethingB.out" that work wrong.
>
> That work's wrong in Bash version 4.4.23(1) and too in
Hello.
If I try in bash this command ex. "rmdir somethingA > somethingA.out
2>&1" work right. But, if I try "rmdir somethingB 2>&1 >
somethingB.out" that work wrong.
That work's wrong in Bash version 4.4.23(1) and too in 5.0.0(1)-rc1:
# v. 4.4.23(1) #
$ mkdir /dev/shm/test
$ cd
>> instead press twice. 4/ and 5 will
> >>> be suggested, but if you press
> >>> you will see that it should suggest the> files in /home.
> >>
> >> It's not a bug. Bash maintains a logical view of the file system and the
> >&g
uld suggest the> files in /home.
>>
>> It's not a bug. Bash maintains a logical view of the file system and the
>> current directory for cd, pwd, and $PWD, as Posix specifies. One of the
>> consequences is that the pathname of the current directory depends on the
&g
of the file system and the
> current directory for cd, pwd, and $PWD, as Posix specifies. One of the
> consequences is that the pathname of the current directory depends on the
> path used to reach it, which affects how bash canonicalizes `..'. Bash is
> consistent in its use of thi
4/ and 5 will
> be suggested, but if you press
> you will see that it should suggest the> files in /home.
It's not a bug. Bash maintains a logical view of the file system and the
current directory for cd, pwd, and $PWD, as Posix specifies. One of the
consequences is that the pat
1 - 100 of 300 matches
Mail list logo
