Re: Suggestion for .bashrc
On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge wrote: > On Thu, Dec 30, 2021 at 08:46:16PM -0800, Kevin O'Gorman wrote: > > So I propose extending the stanza near the end of .bashrc: > > if [ -f ~/.bash_aliases ]; then > > . ~/.bash_aliases > > fi > > That code was written by your operating system vendor, or by your > system administrator, or by you. It's not something that comes from > upstream bash. > > > by following it with > > for __bash_alias in ~/.bash_aliases.d/* ; do > > if [ -f $__bash_alias ]; then > > source $__bash_alias > > fi > > done > > You can edit the file yourself and make it work however you like. You > have the right idea, but I'd write it like this: > > if [[ -d ~/.bash_aliases.d ]]; then > for f in ~/.bash_aliases.d/*; do > Doesn't that shell expansion in the 'for' loop need to be protected somehow so that if there are no files in the directory, the loop does not try to process literally the file '*' in that directory? [[ -f $f ]] && source "$f" > done > fi > > Variable expansions need to be quoted inside [ but not inside [[. > > -- Matthew O. Persico
Re: Suggestion for .bashrc
On Tue, Jan 4, 2022 at 3:38 PM Greg Wooledge wrote: > On Tue, Jan 04, 2022 at 03:34:05PM -0500, Matthew Persico wrote: > > On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge > wrote: > > > You can edit the file yourself and make it work however you like. You > > > have the right idea, but I'd write it like this: > > > > > > if [[ -d ~/.bash_aliases.d ]]; then > > > for f in ~/.bash_aliases.d/*; do > > > > > > > Doesn't that shell expansion in the 'for' loop need to be protected > somehow > > so that if there are no files in the directory, the loop does not try to > > process literally the file '*' in that directory? > > > > [[ -f $f ]] && source "$f" > > > done > > > fi > > That's precisely what the [[ -f $f ]] check is for. You could use -e > instead of -f if you prefer, just in case you ever want it to be able > to source named pipes or something. > > I was reading this in gmail and that example was below the triple dots, so I didn't see it. Face-palm. -- Matthew O. Persico
Re: Feature request
> > On 1/11/22 6:24 AM, Tathastu Pandya via Bug reports for the GNU Bourne > Again SHell wrote: > > Just as PROMPT COMMAND thats get executed every time before any commamd. > Is there a way to execute predefined command after every command is > executedeg. Automatically record the exit status of currentky executed > command to history file immeduately after a command ends or ctrl+c or any > break or exit > > My prompt is '\n[\$? = $?]\n\[\e]0;\u@\h:$$:\w\a\]where : \u@\h \npwd : \w\n[$$] $' It starts with '\n[\$? = $?]\n ' which means that it prints the exit value of the last command. Looks like this: [$? = 0] where : matthew@MONOLITH pwd : ~ [61] $ echo hi there hi there [$? = 0] where : matthew@MONOLITH pwd : ~ [61] $echoi hi Command 'echoi' not found, did you mean: command 'echo' from deb coreutils (8.30-3ubuntu2) Try: sudo apt install [$? = 127] where : matthew@MONOLITH pwd : ~ [61] $ I don't see why you can't write a function that would write the status out to the history file directly using some kind of comment in it and call that function in PS1 as the first command. Or maybe you can mess with the history saving commands to add that. I messed with mine to record PWD in the history file for each command. You can surf https://github.com/matthewpersico/personal if you want to try and dig up how I did that.
Re: Patch for autoload.v3 to allow export of function
Greetings! I have finally gotten around to working on autoload again to ensure that there are no issues. But I have a question about the _AUTOLOADS array, which is used to track what has been autoloaded and is the source of information for the -p command. The code executes a linear scan of the array _AUTOLOADS each time it has to find and element for removal or to make sure it is not about to add a duplicate entry. This is hardly very efficient. Would it be OK to convert that to an associative array (hash to us Perlers) indexed on function name? I ask before submitting the patch because I am worried about backward compatibility; I do not know when hashes were added to bash nor do I know what the policy is about how far back compatibility has to be maintained. Thank you! -- Matthew O. Persico
Re: Patch for autoload.v3 to allow export of function
You'll notice from the dates on this chain that it has been a while that I
have been working on this. There are a number of reasons (like having to
work at my $job), but one of those reasons is a design one.
If you look at the code, there seven functions. Of those, only three are
used to implement autoloading. The other four are for bookkeeping purposes
only, to support the -p (dump) and -u (to remove a function from being
tracked in autoload) options.
The tracking is done with a bash array _AUTOLOADS. All insertions and
removals are processing a linear array - loop and search until you find the
item, copying the other items to a new array. It's all very inefficient,
but since we're dealing with shell, there's not much to do about speed
anyway. At one point, I converted _AUTOLOADS to a bash associative array,
but efficiency isn't the real problem here.
The real problem is that that arrays (associative or otherwise) cannot be
exported to subshells (such as starting up a new xterm), BUT the functions
can. So if you end up with -p and -u unsupportable in subshells, unless you
not only run the autoload commands in the bash profile for logins, but also
in the bashrc for subshells so that you can rebuild _AUTOLOADS, which takes
a lot of extra code, I might add, in the load phase, to make sure we don't
reload the second time around and make sure we get the array right.
Well, as you can see, I've been down the rathole and back and was about to
abandon the work until I came up with a way to avoid all this issues; an
easy way to tell if a function was an autoloaded function no matter how
many shells deep it's been exported. I can even tell whether it is still in
the shim stage or has been executed. But I fear no sane person will agree
with my solution:
Code injection.
It goes like this:
The current set of steps is
1 - Create the shim at autoload time.
2 - First time it's called, the shim finds the file with the function text
and sources it in.
3 - The shim then runs the function with whatever arguments were passed in.
What I propose to do between steps 2 and 3 is
2.1 - After sourcing the function in, type the function to get its text
2.2 - type appears to pretty print function code. No matter how sloppy or
compact your function is on disk, type presents it to you in a particular
format. To wit, for a function 'foo'
foo is a function
foo ()
{
first line of code
}
That's regular. Therefore it can be parsed.
2.3 - With the output of the type command, I strip out line 1 and after
line 3, I add the text
local AUTOLOADED='foo'
2.4 - evaling the modified code updates the function to include that line
2.5 - Determining if a function is autoloaded is as simple as executing
(something like)
$ type foo | grep 'local AUTOLOADED='foo'.
which is REALLY REALLY fast, even under Cygwin on Windows 10. Yeah, that's
one of the environments I'm using for testing.
No more unexportable arrays and hashes. Self documenting. And 'AUTOLOADED'
can be changed to something less likely to clash with existing code. And we
document that any function you are going to autoload must avoid using the
variable AUTOLOADED, or whatever it is eventually.
So, before I post code here, what say you all? Is the idea of doing this
code injection so hideous that it would never be accepted, or is it worth
submitting the code for perusal?
Thank you for your time,
On Sun, Jul 2, 2017 at 12:50 PM, Chet Ramey wrote:
> On 7/1/17 5:50 PM, Matthew Persico wrote:
> > Greetings!
> >
> > I have finally gotten around to working on autoload again to ensure that
> > there are no issues. But I have a question about the _AUTOLOADS array,
> > which is used to track what has been autoloaded and is the source of
> > information for the -p command.
> >
> > The code executes a linear scan of the array _AUTOLOADS each time it has
> to
> > find and element for removal or to make sure it is not about to add a
> > duplicate entry. This is hardly very efficient. Would it be OK to convert
> > that to an associative array (hash to us Perlers) indexed on function
> name?
> >
> > I ask before submitting the patch because I am worried about backward
> > compatibility; I do not know when hashes were added to bash nor do I know
> > what the policy is about how far back compatibility has to be maintained.
>
> Go ahead and submit the patch; if backwards compatibility is an issue, just
> name it `autoload.v4'. Associative arrays have been in bash since
> bash-4.0, which was released in 2009, so including an updated version with
> future bash distributions should not limit its usefulness.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>
--
Matthew O. Persico
Re: Patch for autoload.v3 to allow export of function
Please see the attached 'autoload.v4' and 'autoload.v4.t'.
On Mon, Aug 14, 2017 at 10:30 AM, Chet Ramey wrote:
> On 8/11/17 6:55 PM, Matthew Persico wrote:
>
> > What I propose to do between steps 2 and 3 is
> >
> > 2.1 - After sourcing the function in, type the function to get its text
> > 2.2 - type appears to pretty print function code. No matter how sloppy or
> > compact your function is on disk, type presents it to you in a particular
> > format. To wit, for a function 'foo'
> >
> > foo is a function
> > foo ()
> > {
> > first line of code
> >
> > }
> >
> > That's regular. Therefore it can be parsed.
> >
> > 2.3 - With the output of the type command, I strip out line 1 and after
> > line 3, I add the text
> >
> > local AUTOLOADED='foo'
> >
> > 2.4 - evaling the modified code updates the function to include that line
> >
> > 2.5 - Determining if a function is autoloaded is as simple as executing
> > (something like)
> >
> > $ type foo | grep 'local AUTOLOADED='foo'.
> >
> > which is REALLY REALLY fast, even under Cygwin on Windows 10. Yeah,
> that's
> > one of the environments I'm using for testing.
> >
> > No more unexportable arrays and hashes. Self documenting. And
> 'AUTOLOADED'
> > can be changed to something less likely to clash with existing code. And
> we
> > document that any function you are going to autoload must avoid using the
> > variable AUTOLOADED, or whatever it is eventually.
> >
> > So, before I post code here, what say you all? Is the idea of doing this
> > code injection so hideous that it would never be accepted, or is it worth
> > submitting the code for perusal?
>
> Of course it's worth submitting the code for folks to look at. It might be
> possible to add a couple more checks to insulate it against possible future
> changes to the `type' output.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>
--
Matthew O. Persico
autoload.v4
Description: Binary data
autoload.v4.t
Description: Troff document
Re: Patch for autoload.v3 to allow export of function
It has finally occurred to me after 24 hours that attachments are pretty
useless in this forum. I will repost this evening with the contents in the
mail body. And, since this is not longer a patch but really a rerwite, I'll
use a fresh thread.
On Wed, Aug 16, 2017 at 1:56 AM, Matthew Persico
wrote:
> Please see the attached 'autoload.v4' and 'autoload.v4.t'.
>
> On Mon, Aug 14, 2017 at 10:30 AM, Chet Ramey wrote:
>
>> On 8/11/17 6:55 PM, Matthew Persico wrote:
>>
>> > What I propose to do between steps 2 and 3 is
>> >
>> > 2.1 - After sourcing the function in, type the function to get its text
>> > 2.2 - type appears to pretty print function code. No matter how sloppy
>> or
>> > compact your function is on disk, type presents it to you in a
>> particular
>> > format. To wit, for a function 'foo'
>> >
>> > foo is a function
>> > foo ()
>> > {
>> > first line of code
>> >
>> > }
>> >
>> > That's regular. Therefore it can be parsed.
>> >
>> > 2.3 - With the output of the type command, I strip out line 1 and after
>> > line 3, I add the text
>> >
>> > local AUTOLOADED='foo'
>> >
>> > 2.4 - evaling the modified code updates the function to include that
>> line
>> >
>> > 2.5 - Determining if a function is autoloaded is as simple as executing
>> > (something like)
>> >
>> > $ type foo | grep 'local AUTOLOADED='foo'.
>> >
>> > which is REALLY REALLY fast, even under Cygwin on Windows 10. Yeah,
>> that's
>> > one of the environments I'm using for testing.
>> >
>> > No more unexportable arrays and hashes. Self documenting. And
>> 'AUTOLOADED'
>> > can be changed to something less likely to clash with existing code.
>> And we
>> > document that any function you are going to autoload must avoid using
>> the
>> > variable AUTOLOADED, or whatever it is eventually.
>> >
>> > So, before I post code here, what say you all? Is the idea of doing this
>> > code injection so hideous that it would never be accepted, or is it
>> worth
>> > submitting the code for perusal?
>>
>> Of course it's worth submitting the code for folks to look at. It might be
>> possible to add a couple more checks to insulate it against possible
>> future
>> changes to the `type' output.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>> ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRUc...@case.edu
>> http://cnswww.cns.cwru.edu/~chet/
>>
>
>
>
> --
> Matthew O. Persico
>
--
Matthew O. Persico
Dashes in function names: Undocumented?
I put a bug report into an emacs group because the bash syntax highlighter failed to recognize functions whose names have dashes in them. The maintainer came back with this: I can reproduce this behaviour, but is it really a bug? Aren't the names with '-' invalid? The Bash Reference Manual says: name A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variable and function names. Also referred to as an identifier. https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html I looked at the manual and I didn't see positive or negative acknowledgement that dashes can be used in function names. But it does work. Update to manual? name A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variables. Also referred to as an identifier. function name A word consisting solely of letters, numbers, underscores, dashes, and beginning with a letter or underscore. Function names are used to label shell functions. -- Matthew O. Persico
Re: Dashes in function names: Undocumented?
On Wed, Aug 12, 2020 at 11:06 AM Eli Schwartz wrote: > On 8/12/20 10:51 AM, Matthew Persico wrote: > > I put a bug report into an emacs group because the bash syntax > highlighter > > failed to recognize functions whose names have dashes in them. > > > > The maintainer came back with this: > > > > I can reproduce this behaviour, but is it really a bug? Aren't the > > names with '-' invalid? > > The Bash Reference Manual says: > > name > > A word consisting solely of letters, numbers, and underscores, and > > beginning with a letter or underscore. Names are used as shell > > variable and function names. Also referred to as an identifier. > > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html > > > > I looked at the manual and I didn't see positive or negative > > acknowledgement that dashes can be used in function names. But it does > work. > > > > Update to manual? > > The bash-20191127 snapshot updated the manpage documentation for a > function definition (to align with reality). It is now defined as: > > function fname [()] compound-command [redirection] > > and includes the description: > > When in posix mode, fname must be a valid shell name and may not be the > name of one of the POSIX special builtins. In default mode, a function > name can be any unquoted shell word that does not contain $. > > For context: > > word - A sequence of characters considered as a single unit by the > shell. Also known as a token. > > name - A word consisting only of alphanumeric characters and > underscores, and beginning with an alphabetic character or an > underscore. Also referred to as an identifier. > > > > name > > A word consisting solely of letters, numbers, and underscores, and > > beginning with a letter or underscore. Names are used as shell > > variables. Also referred to as an identifier. > > > > function name > > A word consisting solely of letters, numbers, underscores, dashes, and > > beginning with a letter or underscore. Function names are used to label > > shell > > functions. > > > > > -- > Eli Schwartz > Bug Wrangler and Trusted User > > Thanks. I will take your word for it, as I cannot seem to find that text at https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless that is not the canonical location for the manual. -- Matthew O. Persico
Patch for autoload.v3 to allow export of function
I would like to submit a patch to the autoload.v3 script. The modification would allow the export of the autoloaded function to subshells. autoload() would now take a -x option, pass it into _aload() which would then make the approrpiate calls to export -f. Where should it be discussed and how does one format and submit a patch (fork, clone, pull request or patch submission on the savanah site or something else)? Thank uou -- Matthew O. Persico
