> 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.
> And yet people are so opposed to the option that they want ridiculous
> restrictions like `you can never alias source="source -i"'.
Yeah. I already feel like I'm insane for even suggesting it.
> Because other people don't see the issue the same way you do,
> and have their own way of doing thin
> Or even
>
> PATH=${BASH_SEARCH_PATH-$PATH} . file
>
> without the need to add any options to . or to source.
If you do that, you'll interfere with command search
in the sourced file. They will not be able to find the
programs that would normally be in the PATH if the
variable is overridden p
>> Why not add a -p option to '.' to specify the path to search.
>> That is
>>. -p "${BASH_SEARCH_PATH-${PATH}}" file
>> would work if someone decided to use the
>> BASH_SOURCE_PATH var name to store the path to use
>> (defaulting to $PATH if that one isn't set).
> Believe it or not, I had tho
> Bash would not set this to any value, since it doesn't install anything
> that would use it. To set it is to apply policy.
What I meant to say is that I as the user
can set it globally on my bash initialization
script so that I can always make use of the
new feature. If the act of setting it cha
> It's rare for a topic about adding an import/include function to get
> so much attention like this I think it's time Bash takes the
> opportunity to implement it and hopefully properly.
Yes!! Conpletely agree with you!
> Are you referring to BASH_SOUCE_PATH being a source-only extension to PATH?
I mean that I won't be able to commit a standard loadable script
location to my dotfiles repository if setting BASH_SOURCE_PATH
changes the behavior of source. It could break too many things.
> Yes it allows the locatio
> the real work of the source ('.' really) utility
> is to read the file
That's the work of read.
> parse it, and execute it.
That's the work of eval.
> None of the proposed solutions here do that.
Of course not. I read the proposals.
The point is they probably could.
So why not do it?
A buil
> the library (the top one may be) decide that source -i
> is the general way to go a decide a despotic alias
> source='source -i' this could be a general setup of
> this package manager.
This is not a problem that's introduced by this patch.
People can already do that today. Anyone could write
`a
> distros, sysadmins, and users can already break your scripts
> in plenty of ways -- changing existing shell variables, setting
> shopts your scripts don't account for, etc.
Existing footguns doesn't justify addition of new ones.
We have the ability to prevent a lot of breakage here.
Shouldn't
> The issue is that what you want, and what I want,
> and what konsolebox wants (and everyone else)
> are all slighty different.
The option solution which I proposed is not really in opposition
to anything that anyone else wants. It will not break anything,
it supports the same inputs and use case
> I am xing fingers the consensus, if any of theses takes off,
> is to have the -i implemented (not omitted)
Me too. Do you know anyone else who could be impacted?
Consensus might move in that direction if more voices make
themselves heard on this list.
> if one, distro, sysadmin, and ultimatly
> You've made contradictory statements here.
I don't see how.
> First you said you wanted to put it into your *environment*.
Yes.
> That would cause shell scripts to see it and exhibit a change in behavior.
Only if the -i option is not implemented.
If it is, there will be zero change in behavi
> Setting the variable at all is opting in to new behavior, and you do
> that at your own risk, after reading the documentation and deciding
> that this is what you want.
As the user, it should be my prerogative to set the
variable on my environment and/or rc so that I can
organize my sourceable s
> As with everything.
It doesn't have to be that way. It could be made so that it's harmless,
so that it has no effect at all unless explicitly enabled by an option.
Then there's no need to carefully manage it. Users and packagers
can set it wherever they want without fear of breaking things.
> Y
> 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
> 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
> It has been Bash's convention to allow a non-POSIX feature
> even in POSIX mode when the script explicitly requests it.
I see. I have no objections to that.
My initial implementation also worked like this.
I did it that way because someone explicitly requested that
POSIX mode not be affected in
> 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
> 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.
> Or, at least, this should be an opt-in
> feature that the scripts to set up the
> restricted shells n
I agree that it is not strictly necessary.
It could be implemented without an option.
I personally have no objections to that solution.
My arguments for the option are the following:
- It enhances compatibility
Without the option, source behaves exactly as before.
Existing scripts will wor
Completely agree with your suggestions.
I've proposed suggestion 3 as well in previous
emails but consensus was not reached.
-- Matheus
> 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
> I think we should restrict the search in
> BASH_SOURCE_PATH and shouldn't fall back to local files.
I concur but thought it'd be wise to discuss it first so I left it in.
Users might expect it to respect the configuration option.
I also saw that many of the PATH-like variable defaults
had the cu
Define a build time configurable default value
for the new BASH_SOURCE_PATH variable.
Look for libraries in the user's home directory
as well as the system wide directories.
Signed-off-by: Matheus Afonso Martins Moreira
---
config-top.h | 7 +++
variables.c | 1 +
2 files chang
Behave normally when executed without any options.
Search only BASH_SOURCE_PATH for scripts to source
when isolated mode is enabled via the -i option.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 27 ++-
1 file changed, 26 insertions(+), 1
Make the BASH_SOURCE_PATH variable read-only and unsettable
when the shell is operating in restricted mode. This variable
should be restricted for the same reasons why PATH is restricted.
Signed-off-by: Matheus Afonso Martins Moreira
---
shell.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Extract the file searching algorithm of the source builtin into
a static helper function. Makes the code easier to understand
and separates the searching from the error handling logic.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 59
outside POSIXly correct mode.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/builtins/source.def b/builtins/source.def
index ba5e1596..26040e70 100644
--- a/builtins/source.def
It works just like the find_in_path function
but takes a PATH-like variable name instead.
This allows defining and using more PATH-like
variables much more easily.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 7 +++
findcmd.h | 1 +
2 files changed, 8 insertions(+)
diff
Extract into a dedicated helper function the code which loads
the contents of a file and executes it in the current shell.
This separates this useful functionality from the path resolution
mechanism used by the source builtin.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins
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
source paths to avoid clashes
- Restricted source path variable
Matheus Afonso Martins Moreira (8):
findcmd: parameterize path variable in functions
findcmd: define find_in_path_var function
builtins/source: extract file executor function
builtins/source: refactor file searching function
> Backwards compatibility from the ancient past. Even back then (1989),
> `type' was the only builtin that supported any kind of long option;
> no other builtins ever have.
I see, thanks for clarifying. I will remove the long options.
-- Matheus
> This is your key assertion, and it does not appear to have achieved
> consensus.
That's true, unfortunately.
>> The behavior of the source builtin already has several special cases.
> Do you mean the treatment of the DEBUG trap? That's for the debugger.
I mean that the source builtin already b
> Neither of these requires a new builtin command.
> They require changes to the shell, since they differ from
> existing functionality, but those changes don't have to
> take the form of a builtin.
Builtin was not the correct word for what I meant.
I meant to say there were advantages to implemen
> I've checked the behavior, where the `source' builtin seems to still
> load the non-executable one found first in the path.
I was wrong about that. I derived find_user_library
from find_user_command. That's what I had in mind.
> How do you define `the libraries' out of a wider category of Bash
> 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
> 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 use
> 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 options
> 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.
T
> 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 separat
> 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 arch
> 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 an
> 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 lo
> 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 to
> 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 the
>> A native way to source libraries. Built into bash, available to all users.
> That's the source builtin.
It looks for scripts in directories meant for executables.
It prefers files with the executable bit set.
It's a native way to load bash scripts for sure.
But it's not a native way to load lib
> Your proposition could not be 'builtin', you want a new 'model' with
> 'packages/module'
Yes. However, that was because I did not really know bash module managers
existed.
I immediately adopted a conservative approach once I was informed of their
existence.
I do not intend to develop the imp
> Libraries are 'compiled collection of object module', can be static/dynamic,
> dynamic imply a runtime load.
By this definition, dynamic languages and scripting languages don't have
libraries.
They clearly do have libraries. Sometimes they're called modules but it's the
same thing.
> This is
> 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 of lines" ballpark.
However many lines that is, this feature would allow me
t
> 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 executables
when they might actually be libraries and modules.
> I think every single use of the term "library" in this whole endeavor
> is misleading and misguided.
I don't think so. A library is just a logical collection of code and data
that you can use to implement software. This is a mechanism meant
to load those libraries separately from executables.
T
Define the shorten_long_options helper function that converts
long options to short options which are supported by bash's
builting getopt function.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/bashgetopt.c | 24
builtins/bashgetopt.h | 7 +++
2
Define a build time configurable default value
for the new BASH_LIBRARIES_PATH variable.
Look for libraries in the user's home directory
as well as the system wide directories.
Signed-off-by: Matheus Afonso Martins Moreira
---
config-top.h | 7 +++
variables.c | 1 +
2 files chang
Extract the file searching algorithm of the source builtin into
a static helper function. Makes the code easier to understand
and separates the searching from the error handling logic.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 59
Behave normally when executed without any options.
Search for libraries when library mode is enabled
via the -l or --library options.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtins/source.def
Passing these options to the source builtin
enables library loading mode which restricts
its search path to the directories defined by
the BASH_LIBRARIES_PATH variable.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 23 +--
1 file changed, 21
The search_for_library function is considerably simpler:
it loads absolute paths directly, or searches for libraries
in the directories defined by BASH_LIBRARIES_PATH.
Signed-off-by: Matheus Afonso Martins Moreira
---
builtins/source.def | 14 ++
1 file changed, 14 insertions
with the ability to execute commands
in the library scripts which is a serious and unnecessary limitation.
Introducing a new variable addresses both of these concerns and also
improves performance by reducing the search space.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 12
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
Afonso Martins Moreira
---
builtins/common.c | 64 +
builtins/common.h | 1 +
builtins/source.def | 62 +++
3 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/builtins/common.c b/builtins
ities were reused as much as possible.
Signed-off-by: Matheus Afonso Martins Moreira
Matheus Afonso Martins Moreira (9):
builtins: extract file content executor function
findcmd: parameterize path variable in functions
findcmd: define the user library finder function
bashgetopt: define l
> If your purpose is just to solve a small inconvenience of the `source'
> builtin mixing the namespaces of local scripts, "libraries", and
> executables, I think the suggested `source -i' or `source -l' would be
> fine. I think no additional reasoning is needed.
That is my purpose!
I think I wen
> If the purpose is to introduce a standard module system in Bash,
> I'll have to be opposed to the change because I think the current
> suggestion for `source -i' wouldn't help satisfy that purpose at all.
I think we were unable to reach an understanding because we were both
using the same words
> it doesn't need to be implemented as a builtin
It doesn't need to be implemented this way.. But it could be.
It's true that a whole new builtin was overkill but the discussion
still pointed to a better solution in the form of source --import.
This is a more conservative approach but it's still a
> How is this any different than
The main advantage would be availability of this mechanism
by default in all new versions of bash. This would make it
"native" to the language, the path of least resistance to
reusing bash code. Users will be able to just place the
scripts in the appropriate locat
> You can prepare a separate directory for the script files to source
> and put the directory name at the beginning of PATH, e.g.,
> PATH=~/.config/bash/functions:$PATH.
This is suboptimal. In case the library script cannot found
in the intended directories, it will needlessly search every
othe
> This is debatable. Augmenting PATH with a directory containing
> nonexecutable scripts for sourcing is IMO not that confusing.
That was my original intention but there were objections
to overloading the source builtin with even more behavior.
I thought it was a good point so I decided to prot
> Why does this only find executable files?
My intention was to eliminate as many non-candidate entries
as possible. For example, developers might put data files among
the code files, it would be useful if they were not searched. That's
why I also set the no direcrories flag.
I admit I was somew
> By the name "import", I expect also something like an include guard,
> i.e., it loads the same file only once at most.
This is an excellet idea. I'll try to implement it.
Matheus
-off-by: Matheus Afonso Martins Moreira
---
AUTHORS | 1 +
MANIFEST | 1 +
Makefile.in | 4 +-
builtins/Makefile.in | 6 ++-
builtins/import.def | 99
5 files changed, 108 insertions(+), 3 deletions(-)
create mode
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
code.
The needed functionality was split off from existing code
and into parameterized helper functions that both the old
and the new code could use.
Matheus Afonso Martins Moreira (4):
builtins: extract file content executor function
findcmd: parameterize path variable in functions
findcmd:
The find_user_import function looks for executable scripts
in a separate location meant for reusable libraries and modules,
separate from other executables.
Signed-off-by: Matheus Afonso Martins Moreira
---
findcmd.c | 12
findcmd.h | 1 +
2 files changed, 13 insertions(+)
diff
Afonso Martins Moreira
---
builtins/common.c | 64 +
builtins/common.h | 1 +
builtins/source.def | 62 +++
3 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/builtins/common.c b/builtins
78 matches
Mail list logo
