Date:Thu, 16 May 2024 23:54:12 -0400
From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?=
Message-ID: <0b3fa8d4-7a3f-4bd6-8e8d-f7d1746be...@app.fastmail.com>
| This is the description from the bash.1 that's currently in my local
| repository:
Thanks.
Possibly useful I guess
The devel man page and texinfo manual both describe the upcoming
GLOBSORT variable with the following sentence, which has a stray
comma at the end. (I omitted it in my last message to kre.)
A sort specifier of `nosort' disables sorting completely;
the results are returned in the o
On Thu, May 16, 2024, at 11:36 PM, Robert Elz wrote:
> Date:Thu, 16 May 2024 11:36:50 -0400
> From:Chet Ramey
> Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>
>
> | I have high hopes for `GLOBSORT', though.
>
> That is at least a plausible name - never heard
Date:Thu, 16 May 2024 11:36:50 -0400
From:Chet Ramey
Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>
| You can already do this; there's no reason to add these semantics to a
| variable setting.
How? What I'm looking for is a way to catch accidental
On Fri, May 17, 2024 at 02:23:10AM +, Matheus Afonso Martins Moreira wrote:
> It's also important to consider the opposite situation:
> distributions and/or users setting BASH_SOURCE_PATH globally
> which then results in existing scripts _not_ getting the historical
> behavior which matches wha
> If you don't set BASH_SOURCE_PATH (from the user's perspective;
> I'm not sure what I think about a loaded `library' changing the global
> user settings by setting it), you get the historical behavior.
It's also important to consider the opposite situation:
distributions and/or users setting BAS
On 5/16/24 3:40 PM, Collin Funk wrote:
Hi Chet,
On 5/16/24 7:25 AM, Chet Ramey wrote:
Yes. This was inspired by
https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00158.html
I'm not sure if you have dealt with this particular one yet, but I
would just get rid of the u_char, u_short, u_lo
Hi Chet,
On 5/16/24 7:25 AM, Chet Ramey wrote:
> Yes. This was inspired by
>
> https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00158.html
I'm not sure if you have dealt with this particular one yet, but I
would just get rid of the u_char, u_short, u_long, types. They are old
BSD stuff tha
On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote:
> On 5/15/24 11:31 AM, Koichi Murase wrote:
> > Maybe it was not clear to use `source name' and `source -i name' to
> > describe the idea. I meant I assumed the search domain being
> >
> > * BASH_SOURCE_PATH + PATH + PWD without the optio
On 5/16/24 8:37 AM, Oğuz wrote:
This feature request sounded promising at first, it feels like
bike-shedding now.
Yes, nothing's ever easy. We are quickly approaching diminishing returns.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'
On 5/16/24 11:54 AM, G. Branden Robinson wrote:
At 2024-05-16T11:36:50-0400, Chet Ramey wrote:
On 5/15/24 6:27 PM, Robert Elz wrote:
and any attempt to use a relative path (and you
can exclude ./anything or ../anything from that if you prefer - ie:
Those are not relative paths.
!
POSIX 100
On 5/16/24 7:02 AM, Martin D Keale
(1) it's barely tolerable to add more action-at-a-distance by introducing a
new variable; but adding *invisible* action at a distance is a language
design antipattern. Having `-i` on the `source` command documents that new
behaviour is expected.
What `invis
At 2024-05-16T11:36:50-0400, Chet Ramey wrote:
> On 5/15/24 6:27 PM, Robert Elz wrote:
> > and any attempt to use a relative path (and you
> > can exclude ./anything or ../anything from that if you prefer - ie:
>
> Those are not relative paths.
!
POSIX 1003.1-202x/D4, §3.311 defines "relative pa
On 5/15/24 11:25 AM, Koichi Murase wrote:
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 s
On 5/15/24 6:27 PM, Robert Elz wrote:
All I suggested
was having a BASH_SOURCE_PATH set to the empty string mean that no path
lookup should be done,
You can already do this; there's no reason to add these semantics to a
variable setting.
and any attempt to use a relative path (and you
can e
On 5/15/24 11:31 AM, Koichi Murase wrote:
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 pr
On 5/16/24 12:55 AM, Grisha Levit wrote:
Just moving up the builtins.h include is enough to fix this, but I'm
not sure if an explicit config.h include is needed (or clearer).
Probably the latter.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita
On 5/16/24 12:21 AM, Grisha Levit wrote:
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
Yes. This was inspired by
bad gmail app buggs sorry , missed ending }
[[ $BASH_SOURCE == /* ]] &&
medir=${BASH_SOURCE%/*} || {
[[ $BASH_SOURCE != */* ]] &&
medir=$PWD ||
medir=$PWD/${BASH_SOURCE%/*}
}
On Thu, May 16, 2024, 15:48 alex xmb sw ratchev wrote:
> maybe this one
>
> [[ $BASH_SOURCE == /* ]] &&
> medir=${
maybe this one
[[ $BASH_SOURCE == /* ]] &&
medir=${BASH_SOURCE%/*} || {
[[ $BASH_SOURCE != */* ]] &&
medir=$PWD ||
medir=$PWD/${BASH_SOURCE%/*}
}
On Thu, May 16, 2024, 15:45 alex xmb sw ratchev wrote:
>
>
> On Thu, May 16, 2024, 15:43 alex xmb sw ratchev wrote:
>
>>
>>
>> On Thu, May 16, 20
On Thu, May 16, 2024, 15:43 alex xmb sw ratchev wrote:
>
>
> On Thu, May 16, 2024, 14:37 Oğuz wrote:
>
>> On Wednesday, May 15, 2024, Chet Ramey wrote:
>>
>> > is it more common to have
>> > something like the script in somewhere/bin, files to be sourced in
>> > somewhere/lib, and so on?
>>
>>
On Thu, May 16, 2024, 14:37 Oğuz wrote:
> On Wednesday, May 15, 2024, Chet Ramey wrote:
>
> > is it more common to have
> > something like the script in somewhere/bin, files to be sourced in
> > somewhere/lib, and so on?
>
>
> Not sure how common but this is what makes sense. Or name sourceables
On Wednesday, May 15, 2024, Chet Ramey wrote:
> is it more common to have
> something like the script in somewhere/bin, files to be sourced in
> somewhere/lib, and so on?
Not sure how common but this is what makes sense. Or name sourceables
foo.sh, bar.sh and executables foo, bar so they don't
On Thu, 16 May 2024 at 03:03, Chet Ramey wrote:
> 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 libra
On Thu, May 16, 2024 at 4:59 PM Martin D Kealey wrote:
> On Wed, 15 May 2024 at 16:33, konsolebox wrote:
>>
>> On Wed, May 15, 2024 at 7:16 AM Martin D Kealey
>> wrote:
>>
>> > I'm concerned that doing both would introduce an entirely new dichotomy
>> > for programmers to have to remember, so
On Thu, 16 May 2024 at 02:48, Koichi Murase wrote:
> 2024年5月14日(火) 15:09 Martin D Kealey :
> > 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 $
26 matches
Mail list logo
