On 5/5/24 11:55 PM, Matheus Afonso Martins Moreira wrote:
Such is the extent to which I concur that I find even -l to be irritating.
Well, I don't concur at all. I think it's just the opposite.
I think it's actually the source builtin which incorrectly
implies that all sourced scripts are
On 5/5/24 3:39 PM, Kerin Millar wrote:
Such is the extent to which I concur that I find even -l to be irritating.
The option character isn't important. Is it useful to have an additional
option to `source' that forces it to use $BASH_SOURCE_PATH, or should that
behave like other builtins
On 4/25/24 2:37 AM, Jim Blackson wrote:
Hello GNU,
1. Perhaps there is a broken link in the bread crumb list of the index
page of the Bash Reference Manual, found at:
https://www.gnu.org/software/bash/manual/html_node/index.html
Thanks for the report. I'm not sure if this is an artifact of
On 5/6/24 8:32 PM, John wrote:
Hi!
I believe the Bash Reference Manual is missing a key note for using "set -o".
On the man page for "bash"
(https://tiswww.case.edu/php/chet/bash/bash.html), the following line is
present
* If *-o* is supplied with no /option-name/, the values of the
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 feel
This test fails on systems with recent-ish BSD regex libs, where a
backslash followed by an alphabetic chatacter now throws REG_EESCAPE.
See https://reviews.freebsd.org/D10510
---
tests/cond-regexp3.sub | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/cond-regexp3.sub
On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
> On 5/5/24 3:39 PM, Kerin Millar wrote:
>
>> Such is the extent to which I concur that I find even -l to be irritating.
>
> The option character isn't important. Is it useful to have an additional
If it were of no importance at all, once might
On 5/7/24 1:42 PM, Kerin Millar wrote:
On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
On 5/5/24 3:39 PM, Kerin Millar wrote:
Such is the extent to which I concur that I find even -l to be irritating.
The option character isn't important. Is it useful to have an additional
If it were of
On 5/7/24 3:40 PM, Kerin Millar wrote:
On Tue, 7 May 2024, at 7:14 PM, Chet Ramey wrote:
On 5/7/24 1:42 PM, Kerin Millar wrote:
On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
On 5/5/24 3:39 PM, Kerin Millar wrote:
Such is the extent to which I concur that I find even -l to be irritating.
On Tue, 7 May 2024, at 7:14 PM, Chet Ramey wrote:
> On 5/7/24 1:42 PM, Kerin Millar wrote:
>> On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
>>> On 5/5/24 3:39 PM, Kerin Millar wrote:
>>>
Such is the extent to which I concur that I find even -l to be irritating.
>>>
>>> The option
On 5/7/24 11:55 AM, Grisha Levit wrote:
This test fails on systems with recent-ish BSD regex libs, where a
backslash followed by an alphabetic chatacter now throws REG_EESCAPE.
Thanks for the report.
See https://reviews.freebsd.org/D10510
It's an interesting rationale, at least. I suppose
> a language that has no support for namespaces, awkward scoping rules,
> a problematic implementation of name references, and so on.
I could at least attempt to address those issues.
Namespacing could be as simple as prepending the module name
to the symbols that are being created. Bash seems
> The patches don't apply to the devel branch. You've made patches on
> top of the master branch, but the master branch of Bash is just a
> release branch, where each commit corresponds to a release. You should
> normally work based on the devel branch.
I see. I will rebase the patch on top of
Ok thanx for clarification.
I agry about git{lab,hub} position that's why I added {,whatever} meaning
something really free.
Ok now all is clear and I will not be surprised anymore if some other
'feature' proposal shows up in the future.
> It's simply inconsistent in the present form. Why should only the
> source builtin have the long form of the option? No other builtins
> have the long form of options, which is inconsistent.
Some builtins do support long options, even though it seems
to not be documented. In fact, I based the
On Mon, May 6, 2024, at 1:27 AM, Matheus Afonso Martins Moreira wrote:
>> I fail to see how this could possibly save "thousands and thousands
>> of lines of code".
>
> How many lines of code were needed to implement the module managers?
> Probably a lot of lines. I guessed it was in the "thousands
> It does not. It searches for readable files. Look at
> findcmd.c:find_path_file().
That's true, I stand corrected. I was thinking of the find_user_command function
because it's what I based the find_user_library function on.
They are all implemented in terms of the find_user_command_internal.
> as long as there's no expectation that I'll accept a new feature
> just because someone implemented it.
There is certainly no expectation of the sort. Thanks for considering the patch.
Matheus
> I don't think `$prefix/lib' would be the appropriate place to put the
> script files. /lib directory is traditionally intended for the
> architecture-dependent binary libraries loaded by ld.
Yeah, you're right about that. This should be changed.
> All the other resources independent of the
> I expected that the source builtin without the flag would also
> consider BASH_LIBRARIES_PATH if present, which is more similar to
> Chet's suggestion in the POSIX mode. More specifically, the source
> builtin first searches for BASH_LIBRARIES_PATH if present, or
> otherwise falls back to PATH
> 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 splitting
things into
> I'm thinking of the theoretical case in which a user exports BASH_SOURCE_PATH
> then runs existing scripts - not necessarily of their own design
> that weren't counting on this feature to ever exist.
The option solution completely avoids that possibility.
Existing scripts do not pass any
> Surely these module managers do more than simply implement an
> alternate search path?
Yes. The core feature that they provide, namely module loading,
should be native to bash though. Users who need just that core
feature need not pull in an entire module manager just to get it.
So for those
On Tue, 7 May 2024, at 5:24 AM, Phi Debian wrote:
> On Mon, May 6, 2024 at 7:51 PM Kerin Millar wrote:
>>
>>
>> I'll put it in a little more detail, though no less plainly. I find the
>> terminology of "libraries" and "modules" to be specious in the context of a
>> language that has no
The patches don't apply to the devel branch. You've made patches on
top of the master branch, but the master branch of Bash is just a
release branch, where each commit corresponds to a release. You should
normally work based on the devel branch.
2024年5月5日(日) 18:56 Matheus Afonso Martins Moreira
:
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 very similar
2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira
:
> +/* The default value of the BASH_LIBRARIES_PATH variable
> + which is used by source -l instead of PATH. */
> +#ifndef DEFAULT_LIBRARIES_PATH
> +#define DEFAULT_LIBRARIES_PATH \
> + "~/.local/lib/bash:/usr/local/lib/bash:/usr/lib/bash"
I
Honestly, I share the same feeling as the others about the name
`library'. The use of the ``library'' feels something wrong in this
context.
I still think the variable name should be BASH_SOURCE_PATH. I've
suggested `-l' as an *example*, but that's just because I couldn't
come up with another
2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira
:
> - filename = search_for_file (list);
> + if (!library_mode)
> +filename = search_for_file (list);
> + else
> +filename = search_for_library (list);
I expected that the source builtin without the flag would also
consider
2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira
:
> Define the shorten_long_options helper function that converts
Let's talk about whether we should support the long form of the option
in this patch set.
2024年5月7日(火) 2:11 Matheus Afonso Martins Moreira :
> > incomplete addition of the long
On Sun, 5 May 2024 at 11:50, Koichi Murase wrote:
> > Ideally, they'll be using bash's native import under the hood!
>
> Yes, module managers still need to implement their own "import"
> command while using the proposed "import" primitive under the hood,
> and it's simply interchangeable with
On 5/6/24 9:12 AM, Koichi Murase wrote:
Chet mentioned the additional variable for the locations to search,
but not a new builtin or a flag.
Correct. The $PATH overloading has always been a source of confusion,
or at least something you need to get used to; it would be a benefit
to have a way
On 5/7/24 12:24 AM, Phi Debian wrote:
Just questioning, I really have no idea what is the bash dev team way of
receiving enhancement request.
This list is the traditional place where proposals and discussion happen.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 5/7/24 2:43 AM, Kerin Millar wrote:
Of course, it is sensible to gauge whether there is any potential interest in a
proposed feature prior to submitting patches. Matheus tried to do exactly that
on the 21st April. I may think that the resulting patches have been oversold but
I would not
On 5/6/24 1:21 AM, Phi Debian wrote:
On Sun, May 5, 2024 at 9:47 PM Greg Wooledge wrote:
On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote:
The idea to add a BASH_SOURCE_PATH variable that gets searched before, or
instead of, PATH when using the source builtin -- that
On 5/6/24 1:27 AM, Matheus Afonso Martins Moreira wrote:
Either you add the library directories to the PATH and risk false positives,
or you delete the other directories and make sourced scripts unable to run
commands.
External commands, but there is nothing preventing something like a
36 matches
Mail list logo
