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
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 col
> 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
> If you are talking about the current specific case of path_value, as
> Chet has replied, path_value doesn't return a newly allocated block.
> It just returns a pointer to an existing variable cell owned and
> managed by the global variable context whose root is static. It
> doesn't return or move
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,
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.
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 given the existe
> 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
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 suggested by Chet i
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 +
1
13 matches
Mail list logo
