Re: printf -u "$fd"?
2024年5月22日(水) 0:15 Zachary Santer :
> Additionally, I was hoping the discussion of having a way to make fds
> not CLOEXEC without a loadable builtin[3][4] would get some more
> attention.
I haven't followed the discussion in the original thread for multiple
coprocs, but you can remove CLOEXEC relatively easily [1]:
# Requires Bash >= 4.0
function remove-cloexec {
local fd=$1
if ((fd!=0)); then
builtin eval -- "exec 0<&$fd $fd<&- $fd<&0" &$fd $fd>&- $fd>&1" >/dev/null
fi
}
This uses Bash's behavior of removing CLOEXEC for standard streams
0,1,2. (This behavior is probably undocumented, but I haven't checked
the document carefully). Adding CLOEXEC is more complicated and
relying on some assumptions.
[1]
https://github.com/akinomyoga/ble.sh/blob/59787ee5528a8489e78ba09f712ed4b1f5a8e62f/src/util.sh#L3208-L3215
[2]
https://github.com/akinomyoga/ble.sh/blob/59787ee5528a8489e78ba09f712ed4b1f5a8e62f/src/util.sh#L3114-L3207
--
Koichi
Re: printf -u "$fd"?
On Tue, May 21, 2024 at 3:06 PM Chet Ramey wrote:
>
> On 5/21/24 11:14 AM, Zachary Santer wrote:
> > On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote:
> >>
> >> On 5/21/24 6:17 AM, Zachary Santer wrote:
> >>
> >>> I was wondering what the relationship between the devel and master
> >>> branches was.
> >>
> >> No mystery: the devel branch captures ongoing development, gets the latest
> >> bug fixes, and is where new features appear. The master branch is for
> >> stable releases.
> >
> > But the devel branch won't get changes for bash versions beyond what's
> > in alpha right now?
>
> I'm genuinely curious how you got that from what I said, especially since
> devel has gotten changes since I released bash-5.3-alpha.
Changes I assumed would make it into master while master is bash-5.3.
It sounded like you didn't want to implement anything in devel right
now that wasn't going to make it into bash-5.3. I probably didn't
phrase that very well.
> > Do you create patches from devel and apply them to
> > master?
>
> Sort of, I take the code changes from the appropriate devel commit and
> generate patches against the previous patch level. Sometimes devel and
> previous-release diverge pretty wildly, so it's not always
> straightforward. Then I apply the patches to master and push them as
> separate commits.
>
> > I guess, to be more clear, master is in the history of
> > bash-5.3-alpha,
>
> Yes, I apply the bash testing versions to the last stable release so
> people can, if they wish, see what's changed at a high level. Then I'll
> push bash-5.3-beta on top of alpha, and so on.
>
> > so I assume master will just fast-forward to that
> > point when you're happy with bash-5.3.
>
> Yes.
>
> > Meanwhile, devel is completely
> > off doing its own thing, in terms of the git commit history, Kind of
> > have a hard time wrapping my mind around that.
>
> It's how I set it up when I inherited the git repository. master has always
> been a history of release versions.
And there are some source code things that are different under devel
than in master that aren't meant to ever make it into master, if I
remember correctly? Kind of trying to come up with a better way to do
this that would allow master and devel to continue to serve the
purposes they do now. If you're at all interested.
> >>> I saw that you turned MULTIPLE_COPROCS=1 on by default
> >>> under devel, but haven't touched the somewhat more substantial changes
> >>> that sounded forthcoming, from that whole conversation.
> >>
> >> Which one is that?
> >
> > So this email[1] was just about the config-top.h change, I guess, but
> > in the prior one from you quoted there[2], you seemed to be
> > referencing only removing the coproc once both file descriptors
> > pointing to it have been closed by the user.
>
> I haven't committed to doing anything with how coprocs are reaped, and if I
> do it will certainly not be before bash-5.3.
>
>
> > Additionally, I was hoping the discussion of having a way to make fds
> > not CLOEXEC without a loadable builtin[3][4] would get some more
> > attention.
>
> I haven't returned to it, but kre's syntax is reasonable. The problem with
> doing it is described in
>
> https://lists.gnu.org/archive/html/bug-bash/2024-02/msg00194.html
>
> so it would take more work and thought, and it's not a priority.
>
> > I want to say I tried to do 'tee /dev/fd/A /dev/fd/B' at
> > some point and didn't have the background knowledge to understand why
> > it wouldn't work.
>
> That depends on your /dev/fd implementation. There's nothing in that
> command that bash could affect.
Honestly, I might've been looking at a limitation of MSYS2.
In my Rocky Linux 9.1 VM:
$ bash --version
GNU bash, version 5.1.8(1)-release [...]
$ exec {fd_A}> >( cat > file_A.txt )
$ exec {fd_B}> >( cat > file_B.txt )
$ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}"
words
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
words
$ cat file_B.txt
words
$ exec {fd_A}> >( tr 'w' 'W' > file_A.txt )
$ exec {fd_B}> >( tr 'w' 'W' > file_B.txt )
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
$ cat file_B.txt
$
God knows what I was trying to do the first time, or what's going on
with the second set of procsubs there, but I didn't get "tee:
/dev/fd/N: No such file or directory" like I was expecting. Think I'll
leave this bit of the discussion to the people who know what they're
talking about.
> >>> Do you keep a list of TODOs and things under consideration somewhere?
> >>
> >> I do, it's more of the `folder of ideas' style.
> >
> > Did nosub[5] get in there? Just generalize how coproc fds get handled
> > into something that can be turned on or off for any fd.
>
> No, I don't think it's something I'm going to implement.
Eh well, I thought it would be valuable.
[PATCH] dynamic-complete-history: avoid null ptr qsort UB
$ HISTFILE= bash --norc -in <<< $'#\n#\e\t' bashline.c:3720:16: runtime error: null pointer passed as argument 1, which is declared to never be null /usr/include/stdlib.h:971:30: note: nonnull attribute specified here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bashline.c:3720:16 --- bashline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bashline.c b/bashline.c index 0a4e280e..1f234122 100644 --- a/bashline.c +++ b/bashline.c @@ -3727,7 +3727,7 @@ build_history_completion_array (void) } /* Sort the complete list of tokens. */ - if (dabbrev_expand_active == 0) + if (harry_len && dabbrev_expand_active == 0) qsort (history_completion_array, harry_len, sizeof (char *), (QSFUNC *)strvec_strcmp); } } -- 2.45.1
[PATCH] spell-correct-word: avoid inf loop with neg arg
bash --norc -in <<< $'A \e-\cXs'
---
bashline.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/bashline.c b/bashline.c
index 528f56e0..0a4e280e 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1336,6 +1336,9 @@ bash_spell_correct_shellword (int count, int key)
int wbeg, wend;
char *text, *newdir;
+ if (count < 0)
+count = -count;
+
while (count)
{
bash_backward_shellword (1, key);
--
2.45.1
[PATCH] spell-correct-word: fix small leak
Avoid leak when spell-correcting an empty line.
---
bashline.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/bashline.c b/bashline.c
index 525d065a..528f56e0 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1348,7 +1348,10 @@ bash_spell_correct_shellword (int count, int key)
text = rl_copy_text (wbeg, wend);
if (text == 0 || *text == 0)
- break;
+ {
+ FREE (text);
+ break;
+ }
newdir = dirspell (text);
if (newdir)
--
2.45.1
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On Tue, 21 May 2024 at 03:44, Chet Ramey wrote: > On 5/17/24 1:15 PM, Robert Elz wrote: > > >| If `nosort' means no sorting, there is no imposed ordering, and > ascending > >| and descending are meaningless. > > > > Sure, but directory order, and reverse directory order aren't (and that's > > just a difference between the order in which you create the list as each > > new dirent is read from the directory - does it go at the head or tail). > > That's changing from one random order to another. > In the *general* case yes, the order should be treated as random. For example, readdir on a Linux ext4 fs returns directory entries in pseudo-random order; this is necessary to allow successive readdir calls to traverse a large directory, without skipping or repeating an existing entries, and without locking (so allowing additions, removals, and renamings to continue). (Connected to this, file positions returned by lseek(dir_fd, 0, SEEK_CUR) are pseudorandom numbers identifying the next directory entry to be fetched, not an indication of bytes read so far.) But it's not *always* random. For example, readdir on Linux's /proc/$pid/fd returns filedescriptors in ascending numerical order; likewise readdir on /proc returns process IDs in ascending numerical order (preceded by a bunch of other stuff, in an order that's well-defined in the kernel though perhaps not obvious to most users). Reversing those could be useful to some people. -Martin
Re: printf -u "$fd"?
On 5/21/24 11:14 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and master branches was. No mystery: the devel branch captures ongoing development, gets the latest bug fixes, and is where new features appear. The master branch is for stable releases. But the devel branch won't get changes for bash versions beyond what's in alpha right now? I'm genuinely curious how you got that from what I said, especially since devel has gotten changes since I released bash-5.3-alpha. Do you create patches from devel and apply them to master? Sort of, I take the code changes from the appropriate devel commit and generate patches against the previous patch level. Sometimes devel and previous-release diverge pretty wildly, so it's not always straightforward. Then I apply the patches to master and push them as separate commits. I guess, to be more clear, master is in the history of bash-5.3-alpha, Yes, I apply the bash testing versions to the last stable release so people can, if they wish, see what's changed at a high level. Then I'll push bash-5.3-beta on top of alpha, and so on. so I assume master will just fast-forward to that point when you're happy with bash-5.3. Yes. Meanwhile, devel is completely off doing its own thing, in terms of the git commit history, Kind of have a hard time wrapping my mind around that. It's how I set it up when I inherited the git repository. master has always been a history of release versions. I saw that you turned MULTIPLE_COPROCS=1 on by default under devel, but haven't touched the somewhat more substantial changes that sounded forthcoming, from that whole conversation. Which one is that? So this email[1] was just about the config-top.h change, I guess, but in the prior one from you quoted there[2], you seemed to be referencing only removing the coproc once both file descriptors pointing to it have been closed by the user. I haven't committed to doing anything with how coprocs are reaped, and if I do it will certainly not be before bash-5.3. Additionally, I was hoping the discussion of having a way to make fds not CLOEXEC without a loadable builtin[3][4] would get some more attention. I haven't returned to it, but kre's syntax is reasonable. The problem with doing it is described in https://lists.gnu.org/archive/html/bug-bash/2024-02/msg00194.html so it would take more work and thought, and it's not a priority. I want to say I tried to do 'tee /dev/fd/A /dev/fd/B' at some point and didn't have the background knowledge to understand why it wouldn't work. That depends on your /dev/fd implementation. There's nothing in that command that bash could affect. Do you keep a list of TODOs and things under consideration somewhere? I do, it's more of the `folder of ideas' style. Did nosub[5] get in there? Just generalize how coproc fds get handled into something that can be turned on or off for any fd. No, I don't think it's something I'm going to implement. -- ``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/
[PATCH] rl_change_case: skip over invalid mbchars
Avoid using (size_t)-1 as an offset. Also, not sure it makes sense to
change the case of an invalid byte cast to (wchar_t).
$ bash --norc -in <<< $'\300\e-1\eL'
lib/readline/text.c:1544:26: runtime error: addition of unsigned offset to
0x51100680 overflowed to 0x5110067f
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5110067f at pc
0xc9bb80d44f94 bp 0xd27b8280 sp 0xd27b7a70
READ of size 2 at 0x5110067f thread T0
#0 0xc9bb80d44f90 in __asan_memmove
#1 0xc9bb8134c9a0 in rl_change_case lib/readline/text.c:1544:5
#2 0xc9bb8134d3f0 in rl_downcase_word lib/readline/text.c:1431:11
---
lib/readline/text.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/readline/text.c b/lib/readline/text.c
index 5941b1a2..cdcb7c26 100644
--- a/lib/readline/text.c
+++ b/lib/readline/text.c
@@ -1510,10 +1510,11 @@ rl_change_case (int count, int op)
else
{
m = MBRTOWC (&wc, rl_line_buffer + start, end - start, &mps);
- if (MB_INVALIDCH (m))
- wc = (WCHAR_T)rl_line_buffer[start];
- else if (MB_NULLWCH (m))
- wc = L'\0';
+ if (MB_INVALIDCH (m) || MB_NULLWCH (m))
+ {
+ start = next;
+ continue;
+ }
nwc = (nop == UpCase) ? _rl_to_wupper (wc) : _rl_to_wlower (wc);
if (nwc != wc) /* just skip unchanged characters */
{
--
2.45.1
[PATCH] bashline: small leaks
- free directory_part when completing command words like `~/bin/'
- free contents of matches when completing command words in old-style
command substitutions
---
bashline.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/bashline.c b/bashline.c
index b638e001..525d065a 100644
--- a/bashline.c
+++ b/bashline.c
@@ -2001,6 +2001,11 @@ command_word_completion_function (const char *hint_text,
int state)
free (glob_matches);
glob_matches = (char **)NULL;
}
+ if (directory_part)
+{
+ free (directory_part);
+ directory_part = (char *)NULL;
+}
globpat = completion_glob_pattern (hint_text);
@@ -2451,7 +2456,7 @@ command_subst_completion_function (const char *text, int
state)
filename_text = savestring (text);
if (matches)
{
- free (matches);
+ strvec_dispose (matches);
matches = (char **)NULL;
}
--
2.45.1
[PATCH] execute-named-command: fix small leaks
- free command if it is the empty string
- free command before calling bound function, in case bound function
does not return, like rl_abort
---
lib/readline/text.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/readline/text.c b/lib/readline/text.c
index c5281efe..5941b1a2 100644
--- a/lib/readline/text.c
+++ b/lib/readline/text.c
@@ -2354,9 +2354,11 @@ rl_execute_named_command (int count, int key)
int r;
command = _rl_read_command_name ();
- if (command == 0 || *command == '\0')
+ if (command == 0)
return 1;
- if (func = rl_named_function (command))
+ func = rl_named_function (command);
+ free (command);
+ if (func)
{
int prev, ostate;
@@ -2375,6 +2377,5 @@ rl_execute_named_command (int count, int key)
r = 1;
}
- free (command);
return r;
}
--
2.45.1
Re: printf -u "$fd"?
On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: > > On 5/21/24 6:17 AM, Zachary Santer wrote: > > > I was wondering what the relationship between the devel and master > > branches was. > > No mystery: the devel branch captures ongoing development, gets the latest > bug fixes, and is where new features appear. The master branch is for > stable releases. But the devel branch won't get changes for bash versions beyond what's in alpha right now? Do you create patches from devel and apply them to master? I guess, to be more clear, master is in the history of bash-5.3-alpha, so I assume master will just fast-forward to that point when you're happy with bash-5.3. Meanwhile, devel is completely off doing its own thing, in terms of the git commit history, Kind of have a hard time wrapping my mind around that. > > I saw that you turned MULTIPLE_COPROCS=1 on by default > > under devel, but haven't touched the somewhat more substantial changes > > that sounded forthcoming, from that whole conversation. > > Which one is that? So this email[1] was just about the config-top.h change, I guess, but in the prior one from you quoted there[2], you seemed to be referencing only removing the coproc once both file descriptors pointing to it have been closed by the user. Additionally, I was hoping the discussion of having a way to make fds not CLOEXEC without a loadable builtin[3][4] would get some more attention. I want to say I tried to do 'tee /dev/fd/A /dev/fd/B' at some point and didn't have the background knowledge to understand why it wouldn't work. > > So I take it > > MULTIPLE_COPROCS=1 will be enabled in bash-5.3 but other potential > > changes would come later? > > Probably, yes. > > > Do you keep a list of TODOs and things under consideration somewhere? > > I do, it's more of the `folder of ideas' style. Did nosub[5] get in there? Just generalize how coproc fds get handled into something that can be turned on or off for any fd. [1] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00149.html [2] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00105.html [3] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00085.html [4] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00100.html [5] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00087.html
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On 5/21/24 1:55 AM, Phi Debian wrote: The idea started before the current discussion as a way to avoid overloading PATH in the source builtin: https://lists.gnu.org/archive/html/help-bash/2024-04/msg00022.html Some thought 'source' was a good candidate for this, except that source is a read/parse/eval feature while the intention was more a read/parse for the benefit of the 'importer' You can't import function definitions without the `eval' step. so construct like hobbit:~$ PATH=. source bar is perfectly ledgit if we are honest and admit bar is an import only and execute no code, simply bring functions. So PATH=$BASH_SOURCE_DIR . greatlib is the way to go, still assuming libs are functions/vars only and no code execution. As soon as the 'library' concept assume that eval is also possible, along with read/parse, then kaboom we need PATH back so the PATH=$PATH:/path/to/lib . There are workarounds for this, but they would require these package managers to change. Real life package actually require the eval, because it is the way to configure a 'library' depending the user context. Same. 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't know if that would be good enough for the initial purpose. Apparently not, since there's been an example autoload function in the tree for 30 years. -- ``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/
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On Tue, May 21, 2024 at 1:17 PM Koichi Murase wrote: > There are already shell-function implementations at > /examples/functions/autoload* in the Bash source. They reference FPATH > to load functions, though one needs to call `autoload' for each > function in advance (by e.g. `autoload "$fpath_element"/*' ). > > However, I personally do not think the FPATH mechanism is useful > because a file can only contain one function per file. Significantly > non-trivial functions are usually implemented by a set of helper > functions or sub-functions. Also, in libraries, we usually have a set > of functions that are closely related to one another and share the > implementations. I don't think it is practical to split those > functions into dozens or hundreds of files. It would also be slow to > read many different files, which requires access to random positions > on the disk. > Jeez, I forgot about this examples/functions/autoload. First of all thanx for pointing it, it demonstrate that things can be implemented as bash code (not C hack in bash) at least in the experimental phase. Second, there is no such limitation about 1 source 1 function mapping, since it is sourced any functions defines in the files become available. This open two path. 1 package setup function is autoloaded bringing all the other function that are now callable Say file foo defines foo() bar() then autoload foo() brings both foo() and bar(), if foo is the setup thing for file foo then the doc sez autoload foo to bring up bar() along. Another path is to have a symlink on each 'exported' function on the file foo, so a ln -s foo bar would make bar autoloadable. Note I used 'exported' here meaning the foo file may define a lot of function, only the exposed API one need a symlink. The real divergence from this autoload, and the ksh93 one is that ksh93 will try an autoload on foo using FPATH on the 'command-not-found' situation, something bash don't handle in the user context (it does it in a subshell for unknown reasons). So basically in ksh93 script, beside setting FPATH, you simply call functions directly, on command-not-found then try FPATH to find your function and if found proceed with the load, define func, run setup code, and run the func with parameters... This is neat, but the fact we don't have that on bash is no big deal, we can live without it, again no need to break things that works.
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On 5/21/24 12:49 AM, konsolebox wrote: `Properly' is clearly in the eye of the beholder. I'm sorry if I have to sound assertive on this one but I thoroughly thought about these things years ago and made a framework that works on a multitude of shells, allows both simple and pattern-based targets, and can be compiled (merged into a single file) with simple usage. Not to mention I actually wrote a multi-script application I know what people who write one want. Thanks, this proves my point. You clearly have your idea about what makes such a feature valuable. -- ``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/
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On Tue, May 21, 2024 at 1:15 PM Greg Wooledge wrote: > On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira > wrote: > > > the schizophrenic nature of the feature > > > > First the feature was "irritating" ... Now it's "schizophrenic" ? > > I must be mentally ill for trying to contribute this? > > > > Yeah, I'm done. > > I don't think "schizophrenic" was used as an insult. Rather, it looks > like an attempt to describe the fact that everyone in the thread has a > different concept and/or experience regarding how 'source' and '.' > should work. > > Well, what I really meant was that there are 2 directions one with read/parse the other read/parse/eval and not being able to make a mind, like the Buridan ass https://en.wikipedia.org/wiki/Buridan%27s_ass 'import' read/parse (along with a PATH var) make sense and don't break interfere with source A 'source' read/parse/eval is there with its semantic and should not go away. An 'import' with source look alike and tweaking its flags and semantic is border line, besides, it and can be implemented in shell only with no bash modification, there is no perf consideration here, we are not on the perf path, unless one come up with a source in the inner loop :-) No offense, just pointing that these two path sounds not mixable, an implementation of your $BASH_SOURCE_PATH can be all done in shell in one of your libs, (say your bootstrap lib) whence this one is loaded, it can load all the others.
Re: printf -u "$fd"?
On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and master branches was. No mystery: the devel branch captures ongoing development, gets the latest bug fixes, and is where new features appear. The master branch is for stable releases. I saw that you turned MULTIPLE_COPROCS=1 on by default under devel, but haven't touched the somewhat more substantial changes that sounded forthcoming, from that whole conversation. Which one is that? So I take it MULTIPLE_COPROCS=1 will be enabled in bash-5.3 but other potential changes would come later? Probably, yes. Do you keep a list of TODOs and things under consideration somewhere? I do, it's more of the `folder of ideas' style. -- ``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/
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On Tue, May 21, 2024, 13:18 Koichi Murase wrote: > 2024年5月21日(火) 14:56 Phi Debian : > > Apparently konsolebox wrote a package manager, and survived the source > 'as > > is', yet he still advocate for 'enhancement'. I do have a package manager > > too, and survived source 'as is' and don't require any enhancement. > > I'm not sure if it is the case for konsolebox, but I think it is valid > to suggest including the features that turned out to be useful in > maintaining a package manager as built-in ones. Those suggested > features are meant to replicate the useful part of the features of the > package manager, so it is not surprising that the suggested features > are not needed for the package manager itself. > > That said, I think it would be difficult to reach an agreement on the > detailed behavior of the suggested features to make them consistent > with many existing package managers. > > > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > > know if that would be good enough for the initial purpose. > > There are already shell-function implementations at > /examples/functions/autoload* in the Bash source. They reference FPATH > to load functions, though one needs to call `autoload' for each > function in advance (by e.g. `autoload "$fpath_element"/*' ). > > However, I personally do not think the FPATH mechanism is useful > because a file can only contain one function per file. Significantly > non-trivial functions are usually implemented by a set of helper > functions or sub-functions. Also, in libraries, we usually have a set > of functions that are closely related to one another and share the > implementations. I don't think it is practical to split those > functions into dozens or hundreds of files. It would also be slow to > read many different files, which requires access to random positions > on the disk. > for the overall thread : sorry , i cant read that much text of ya' all but i have a question and related information to share question : is this one-thing-per-file sourcing ? i made long ago a project that has different dirs , contain different type of files ( function , alias , .. ) each one per file , and the name of the file , in the dir , is then its identifier in the code say proj/func/bla will result in bla() with the files comtent .. is it such u discuss here .. if so .. i have big experience and wanna talk more about such just .. .. greets .. -- > Koichi > >
Re: [PATCH v2 5/8] builtins/source: parse the -i option
2024年5月21日(火) 14:56 Phi Debian : > Apparently konsolebox wrote a package manager, and survived the source 'as > is', yet he still advocate for 'enhancement'. I do have a package manager > too, and survived source 'as is' and don't require any enhancement. I'm not sure if it is the case for konsolebox, but I think it is valid to suggest including the features that turned out to be useful in maintaining a package manager as built-in ones. Those suggested features are meant to replicate the useful part of the features of the package manager, so it is not surprising that the suggested features are not needed for the package manager itself. That said, I think it would be difficult to reach an agreement on the detailed behavior of the suggested features to make them consistent with many existing package managers. > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > know if that would be good enough for the initial purpose. There are already shell-function implementations at /examples/functions/autoload* in the Bash source. They reference FPATH to load functions, though one needs to call `autoload' for each function in advance (by e.g. `autoload "$fpath_element"/*' ). However, I personally do not think the FPATH mechanism is useful because a file can only contain one function per file. Significantly non-trivial functions are usually implemented by a set of helper functions or sub-functions. Also, in libraries, we usually have a set of functions that are closely related to one another and share the implementations. I don't think it is practical to split those functions into dozens or hundreds of files. It would also be slow to read many different files, which requires access to random positions on the disk. -- Koichi
Re: [PATCH v2 5/8] builtins/source: parse the -i option
On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira wrote: > > the schizophrenic nature of the feature > > First the feature was "irritating" ... Now it's "schizophrenic" ? > I must be mentally ill for trying to contribute this? > > Yeah, I'm done. I don't think "schizophrenic" was used as an insult. Rather, it looks like an attempt to describe the fact that everyone in the thread has a different concept and/or experience regarding how 'source' and '.' should work.
Re: printf -u "$fd"?
On Mon, May 20, 2024 at 3:03 PM Chet Ramey wrote: > > On 5/17/24 10:53 PM, Zachary Santer wrote: > > > So here's another tangent, but has it been considered to add an option > > to the printf builtin to print to a given file descriptor, rather than > > stdout? If printing to a number of different file descriptors in > > succession, such an option would appear to have all the same benefits > > as read's -u option. > > It doesn't actually save anything; it's just syntactic sugar. Since > `printf' uses stdio internally (as opposed to `read', which uses the > supplied file descriptor directly), you're still going to have to dup2 > it internally somewhere. dprintf could do some of the work here, and bash > has a replacement for systems where it's missing, but that's more than I > want to change before bash-5.3 comes out. Maybe after that. I was wondering what the relationship between the devel and master branches was. I saw that you turned MULTIPLE_COPROCS=1 on by default under devel, but haven't touched the somewhat more substantial changes that sounded forthcoming, from that whole conversation. So I take it MULTIPLE_COPROCS=1 will be enabled in bash-5.3 but other potential changes would come later? Do you keep a list of TODOs and things under consideration somewhere?
Re: [PATCH v2 5/8] builtins/source: parse the -i option
> the schizophrenic nature of the feature First the feature was "irritating" ... Now it's "schizophrenic" ? I must be mentally ill for trying to contribute this? Yeah, I'm done.
