If a completion function installs a new compspec and returns 124, and
the new compspec is for something other than the exact name currently
being completed (i.e. a new default compspec, or a compspec for the
basename of a command being completed that includes a slash), the newly
installed compspec
When building with glibc and an -std= arg in CFLAGS, asort and cat
fail to build since sigsetjmp is guarded by _POSIX_C_SOURCE
In file included from bashjmp.h:24,
from shell.h:25,
from examples/loadables/cat.c:30:
include/posixjmp.h:29:25: error: unknown type
Since 9c430f6b changed some files to no longer include config.h,
building with glibc and an -std= in CFLAGS fails because getopt,
used in support/bashversion.c and mksyntax.c, is guarded by
_POSIX_C_SOURCE >= 2 || _XOPEN_SOURCE
support/bashversion.c:69:17: warning: implicit declaration of
On Thu, May 16, 2024 at 10:51:01AM +0700, Robert Elz wrote:
> Personally, I don't think there is anything common here at all, most
> scripts don't fetch bits from other places, everything simply goes in
> the script, and the need for the '.' command at run time is avoided.
>
> In general, I
Date:Wed, 15 May 2024 11:03:12 -0400
From:Chet Ramey
Message-ID:
| That assumes a flat directory structure for the script and its associated
| files, correct? How common is that really? Or is it more common to have
| something like the script in somewhere/bin,
Date:Wed, 15 May 2024 09:19:06 -0400
From:Chet Ramey
Message-ID: <86e381d8-dc83-4ef8-90e6-122468fa4...@case.edu>
| Why make it different from other PATH-like variables, where a null
| component is equivalent to "."?
Because having two ways to do the same thing
2024年5月15日(水) 22:28 Chet Ramey :
> On 5/14/24 5:26 PM, Koichi Murase wrote:
> > I see. I was assuming that users who want to completely turn off the
> > new feature would set an empty BASH_SOURCE_PATH (for both cases
> > `source name' and `source -i name').
>
> If you don't want to use
2024年5月15日(水) 22:21 Chet Ramey :
> On 5/14/24 7:15 PM, Koichi Murase wrote:
> > In case we talk about different designs, I assume the following one:
> >
> > * `source name' searches the files in BASH_SOURCE_PATH, PATH, and the
> > current working directory.
>
> No, I'm proposing that this behavior
On 5/14/24 4:10 AM, konsolebox wrote:
On Tue, May 14, 2024 at 2:09 PM Martin D Kealey wrote:
1. I therefore propose that where a relative path appears in
BASH_SOURCE_PATH, it should be taken as relative to the directory
containing $0 (after resolving symlinks), rather than relative to $PWD.
2024年5月15日(水) 22:13 Chet Ramey :
> On 5/14/24 4:48 PM, Koichi Murase wrote:
> > However, at the same time, I think the new option could be justified
> > from the viewpoint of language design. If we have a new namespace
> > ``BASH_SOURCE_PATH'' for the scripts to be sourced, it would be neat
> > to
On 5/14/24 2:08 AM, Martin D Kealey wrote:
I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would
like to suggest three tweaks to its semantics.
A common pattern is to unpack a script with its associated library & config
files into a new directory, which then leaves a
On 5/15/24 10:46 AM, Koichi Murase wrote:
Yeah, as far as we resolve the paths by ourselves and specify the
absolute path to the `source' builtin, it would reliably work. Even
BASH_SOURCE_PATH is unnecessary.
kre made the same point earlier.
--
``The lyf so short, the craft so long to
2024年5月14日(火) 15:09 Martin D Kealey :
> A common pattern is to unpack a script with its associated library & config
> files into a new directory, which then leaves a problem locating the
> library files whose paths are only known relative to $0 (or
> ${BASH_SOURCE[0]}).
>
> 1. I therefore propose
2024年5月15日(水) 13:13 Peng Yu :
> On Tue, May 14, 2024 at 3:35 AM Koichi Murase wrote:
> > I totally agree that we should have a way to specify the files in
> > subdirectories by the path relative to the current script file.
>
> I currently use something like this to source script files relatively.
On 5/14/24 2:08 AM, Martin D Kealey wrote:
2. Search BASH_SOURCE_PATH when any relative path is given, not just a path
that lacks a '/', so that libraries can be organized into subdirectories.
This is already the behavior when not in posix mode.
--
``The lyf so short, the craft so long to
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
On 5/14/24 7:50 PM, Matheus Afonso Martins Moreira wrote:
The first thing I did after reading that was look up this find_in_path
function which I had somehow missed. I found that indeed it's the
right solution and agreed with him. However, I also found that it
takes as its string parameter a
On 5/14/24 6:22 PM, Matheus Afonso Martins Moreira wrote:
Or you could simply ignore BASH_SOURCE_PATH in restricted mode.
Then the restricted shells will not have access to this new functionality.
I thought it could be useful if properly integrated.
It would require updating all restricted
On 5/14/24 5:26 PM, Koichi Murase wrote:
I see. I was assuming that users who want to completely turn off the
new feature would set an empty BASH_SOURCE_PATH (for both cases
`source name' and `source -i name').
If you don't want to use BASH_SOURCE_PATH, don't set BASH_SOURCE_PATH,
and unset
On 5/14/24 7:15 PM, Koichi Murase wrote:
In case we talk about different designs, I assume the following one:
* `source name' searches the files in BASH_SOURCE_PATH, PATH, and the
current working directory.
No, I'm proposing that this behavior be the default, without the option:
* `source
On 5/14/24 5:40 PM, Robert Elz wrote:
Date:Tue, 14 May 2024 15:51:10 -0400
From:Chet Ramey
Message-ID:
| What do folks think about forcing an option to enable using
| BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally
| think it is
On 5/14/24 4:48 PM, Koichi Murase wrote:
However, at the same time, I think the new option could be justified
from the viewpoint of language design. If we have a new namespace
``BASH_SOURCE_PATH'' for the scripts to be sourced, it would be neat
to have an option to specify the namespace
On 5/14/24 6:07 PM, Dan Shelton wrote:
On Fri, 26 Apr 2024 at 15:10, Chet Ramey wrote:
On 4/25/24 9:56 PM, Dan Shelton wrote:
Everyone seems to support MAKEFLAGS by now, and it's part of POSIX, so
maybe we delete $(MFLAGS) and rely on make to pass MAKEFLAGS to submakes
in the environment.
> Thanks. I'll add a call to gettext() that will happen right after bash sets
> its default values for the various locale categories.
When building the latest commit on `devel`
(`b3d8c8a4e7c5417d986f93f646ea740cb13c08d7`) this issue no longer occurs.
Thanks!
24 matches
Mail list logo
