I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same directories to the path if I run new interactive shells, so I always add
them to .bash_profile.

Now, if I want to add a new directory to the current shell, I guess I'm
left with adding it interactively and also adding to .bash_profile for
the next login. This is what I have been doing.

The question is --- how do you manage your PATH? Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Meredith Montgomery <mmontgomery@levado.to> writes:

I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same >directories to the path if I run new interactive shells, so I always add
them to .bash_profile.

Now, if I want to add a new directory to the current shell, I guess I'm
left with adding it interactively and also adding to .bash_profile for
the next login. This is what I have been doing.

The question is --- how do you manage your PATH? Thanks!

This is using the Korn shell (which was the reference shell for POSIX):

These functions are defined in my .kshrc. I'm not sure if bash supports the second line of 'remove_from_path'.

function remove_from_path
{
ppp=:${PATH}:
ppp=${ppp//:${1}:/:}
ppp=${ppp#:}
ppp=${ppp?:}
PATH=${ppp}
}

function add_to_path
{
remove_from_path "${1}"
PATH="${PATH}:${1}"
}

function prepend_to_path
{
remove_from_path "${1}"
PATH="${1}:${PATH}"
}

remove_from_path /opt/subversion-1.8.14/bin
add_to_path /nfs/fs12/scott/compilers/aarch64-tools-182/bin
prepend_to_path ~/bin

The functions can be invoked interactively as well.

remove_from_path ""

will remove empty paths from PATH.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2021-11-22, Meredith Montgomery wrote:

I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same directories to the path if I run new interactive shells, so I always add
them to .bash_profile.

Now, if I want to add a new directory to the current shell, I guess I'm
left with adding it interactively and also adding to .bash_profile for
the next login. This is what I have been doing.

The question is --- how do you manage your PATH? Thanks!

I try not to change it, for the reasons you list. My only configuration
is in ~/.zlogin (I use zsh rather than bash):

export PATH="${HOME}/bin:${PATH}"

When and why do you need to change it more often? In the distant
past, it was common for software to install into /opt/the_software_package/
and that meant you had to add it to the search path.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Meredith Montgomery <mmontgomery@levado.to> writes:

I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same directories to the path if I run new interactive shells, so I always add
them to .bash_profile.

What’s the use case for starting an interactive shell from within an interacive shell?

Now, if I want to add a new directory to the current shell, I guess I'm
left with adding it interactively and also adding to .bash_profile for
the next login. This is what I have been doing.

I don’t add new persistent path entries often enough for this to be an
issue.

The question is --- how do you manage your PATH? Thanks!

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jorgen Grahn , dans le message
<slrnspp5e3.1rfm.grahn+nntp@frailea.sa.invalid>, a écrit :

I try not to change it, for the reasons you list. My only configuration
is in ~/.zlogin (I use zsh rather than bash):

export PATH="${HOME}/bin:${PATH}"

If you are using zsh, then the proper place to set up environment variables
is ~/.zshenv.

When and why do you need to change it more often?

It is not a matter if it changing frequently, it is a matter of each
recursive invocation adding its own copy.

I solve the issue globally in my .zshenv with:

[[ "$ZSHENV_USER" == $UID-1 ]] && return
export ZSHENV_USER=$UID-1

If I want the file to take effect, I change the 1 into 2 or back.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-22, Meredith Montgomery wrote:

The question is --- how do you manage your PATH? Thanks!

I use bash as my shell. My shell dotfiles are probably more complex than
they need to be, but I configure $PATH in ~/.env which is sourced by ~/.bash_profile.

At the end of ~/.env I run the following to remove duplicate entries
that may have crept in:

PATH=$(printf %s "$PATH" | awk -vRS=: '!a[$0]++' | paste -s -d:)

So, I can just add a new PATH entry to ~/.env and then source the file (assuming that everything in ~/.env is idempotent)


Jeremy Brubaker

--
A language that doesn't have everything is actually easier to program
in than some that do.
-- Dennis M. Ritchie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/23/21 7:27 AM, Jeremy Brubaker wrote:

I use bash as my shell. My shell dotfiles are probably more complex than
they need to be, but I configure $PATH in ~/.env which is sourced by ~/.bash_profile.

I wonder what the overlap is between people that /frequent/ this
newsgroup and the people that have -- let's say -- non-trivial dot
files. ;-)

At the end of ~/.env I run the following to remove duplicate entries
that may have crept in:

PATH=$(printf %s "$PATH" | awk -vRS=: '!a[$0]++' | paste -s -d:)

Interesting.

That works in Zsh and Bash on contemporary systems. However I had to
slightly modify it for an old FreeBSD 6.x system that I have access to.

PATH=$(printf %s ${PATH} | awk -vRS=: '!a[$0]++' | paste -s -d: -)

So, I can just add a new PATH entry to ~/.env and then source the file (assuming that everything in ~/.env is idempotent)

I like the fact that I can add / pre-pend directories that /I/ want in
the PATH to the system's /default/ PATH and then use the above method to
make sure that there aren't any duplicate directories in the PATH.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same
directories to the path if I run new interactive shells, so I always add
them to .bash_profile.

What’s the use case for starting an interactive shell from within an interacive shell?

You know, say, tail -f /var/log/messages just to monitor it while you
work on something else in some other shell.

Now, if I want to add a new directory to the current shell, I guess I'm
left with adding it interactively and also adding to .bash_profile for
the next login. This is what I have been doing.

I don’t add new persistent path entries often enough for this to be an issue.

Good point, like others also mentioned. I asked because usually there's something really smart that you guys do.

The question is --- how do you manage your PATH? Thanks!

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeremy Brubaker <jbrubake@orionarts.invalid> writes:

On 2021-11-22, Meredith Montgomery wrote:

The question is --- how do you manage your PATH? Thanks!

I use bash as my shell. My shell dotfiles are probably more complex than
they need to be, but I configure $PATH in ~/.env which is sourced by ~/.bash_profile.

At the end of ~/.env I run the following to remove duplicate entries
that may have crept in:

PATH=$(printf %s "$PATH" | awk -vRS=: '!a[$0]++' | paste -s -d:)

So, I can just add a new PATH entry to ~/.env and then source the file (assuming that everything in ~/.env is idempotent)

That's pretty nice! Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Kettlewell , dans le message
<87k0gztg3y.fsf@LkoBDZeT.terraraq.uk>, a écrit :

What’s the use case for starting an interactive shell from within an interacive shell?

Let me see.

Maybe you use startx rather than a display manager, then all your
interactive shells in xterms are descended from the interactive shell in the console.

Maybe you use ":shell" to get a shell from within your editor and do a quick fix without opening a new xterm and navigating to the proper directory.

Maybe you need to run a dangerous command (git reset --hard) and do not want
a loaded gun in your history: a subshell is a simple way of isolating the history.

Maybe you often need to mount a device, copy file automatically, then copy files selectively, then unmount the device: a script starting an interactive shell for the selective copy is a nice solution.

Do I need to continue ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-23, Meredith Montgomery wrote:

Richard Kettlewell <invalid@invalid.invalid> writes:

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

If you are adding to $PATH in .bashrc, yes. IMHO, $PATH should only be
set once on login (through either .{,bash_}profile or .xsession. It
should *not* be set in .bashrc.

There is too much advice on dotfiles that simply says something along
the lines of "put everything in .bashrc and then source that from .bash_profile" which completely defeats the purpose of how dotfiles
*should* be used. And don't get me started on .xsession/.xinitrc.

--
Jeremy Brubaker
јЬruЬаkе@оrіоnаrtѕ.іо

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-23, Grant Taylor wrote:

On 11/23/21 7:27 AM, Jeremy Brubaker wrote:

I use bash as my shell. My shell dotfiles are probably more complex than
they need to be

I wonder what the overlap is between people that /frequent/ this
newsgroup and the people that have -- let's say -- non-trivial dot
files. ;-)

For sure. I troll GitHub periodically for ideas but I'm always looking
for more.

At the end of ~/.env I run the following to remove duplicate entries
that may have crept in:

PATH=$(printf %s "$PATH" | awk -vRS=: '!a[$0]++' | paste -s -d:)

That works in Zsh and Bash on contemporary systems. However I had to slightly modify it for an old FreeBSD 6.x system that I have access
to.

PATH=$(printf %s ${PATH} | awk -vRS=: '!a[$0]++' | paste -s -d: -)

Interesting. GNU coreutils paste treats no file argument as meaning
stdin. Apparantly FreeBSD 6 doesn't.

So, I can just add a new PATH entry to ~/.env and then source the file
(assuming that everything in ~/.env is idempotent)

I like the fact that I can add / pre-pend directories that /I/ want in
the PATH to the system's /default/ PATH and then use the above method to
make sure that there aren't any duplicate directories in the PATH.

I mostly only use my dotfiles on my own system, so I haven't needed to defensively add PATH entries, but that is a good point. I used to have a
bunch of PATH-manipulation functions I found somewhere, but I realized I
never used them. The only one I used was called 'puniq' which I replaced
with the one-liner because I only needed to call it once.

--
Jeremy Brubaker
јЬruЬаkе@оrіоnаrtѕ.іо

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2021-11-23, Nicolas George wrote:

Richard Kettlewell , dans le message
<87k0gztg3y.fsf@LkoBDZeT.terraraq.uk>, a ??crit??:

What???s the use case for starting an interactive shell from within an
interacive shell?

Let me see.

Maybe you use startx rather than a display manager, then all your
interactive shells in xterms are descended from the interactive shell in the console.

Or similarly, screen(1) and tmux(1) sessions.

Maybe you use ":shell" to get a shell from within your editor and do a quick fix without opening a new xterm and navigating to the proper directory.

Maybe you need to run a dangerous command (git reset --hard) and do not want a loaded gun in your history: a subshell is a simple way of isolating the history.

Those were the three common cases I could think of, too. Only one of
them has the second interactive shell as the child of the first one,
but in all of them, the environment is affected twice by interactive
shell startup.

Maybe you often need to mount a device, copy file automatically, then copy files selectively, then unmount the device: a script starting an interactive shell for the selective copy is a nice solution.

Do I need to continue???

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Meredith Montgomery <mmontgomery@levado.to> writes:

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I know .bash_profile runs when I log in and it runs .bashrc when I run
it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same >>> directories to the path if I run new interactive shells, so I always add >>> them to .bash_profile.

What’s the use case for starting an interactive shell from within an
interacive shell?

You know, say, tail -f /var/log/messages just to monitor it while you
work on something else in some other shell.

I don’t see where the recursive shells come from in that case. I might
run tail in the background, or more likely in a completely separate
terminal.

The question is --- how do you manage your PATH? Thanks!

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

Shells in terminal windows have two copies of some things in PATH, which probably means something the X session startup sourced .bashrc. But
that’s as far as it gets.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nicolas George <nicolas$george@salle-s.org> writes:
[...]

Maybe you use ":shell" to get a shell from within your editor and do a quick fix without opening a new xterm and navigating to the proper directory.

[...]

Hmm. I hardly ever use ":shell" in vim; rather I use Ctrl-Z to suspend
the editor, then "fg" to resume the editing session. The shell then has
all my history and other context. (I often have several suspended vim
sessions under a single shell session.)

I'm not saying there's anything wrong with ":shell", but I'm curious
what advantages it has over Ctrl-Z.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-23, Richard Kettlewell wrote:

Shells in terminal windows have two copies of some things in PATH,
which
probably means something the X session startup sourced .bashrc. But

Which it has no business doing, not that it stops it from happening.

--
() www.asciiribbon.org | Jeremy Brubaker
/\ - against html mail | јЬruЬаkе@оrіоnаrtѕ.іо

Art is a lie which makes us realize the truth. -- Picasso

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nicolas George <nicolas$george@salle-s.org> writes:

Maybe you need to run a dangerous command (git reset --hard) and do not want a loaded gun in your history: a subshell is a simple way of isolating the history.

I put a space at the start of commands I don’t want in history (see HISTCONTROL variable).

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-23 19:34, Jeremy Brubaker wrote:

There is too much advice on dotfiles that simply says something along
the lines of "put everything in .bashrc and then source that from .bash_profile" which completely defeats the purpose of how dotfiles
*should* be used. And don't get me started on .xsession/.xinitrc.

and that people source .bashrc is totally not justified because all bash instances are guaranteed to be derived from a login shell and which type of shell is created when is very clearly covered by simple-to-understand rules.

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/23/21 1:45 AM, Richard Kettlewell wrote:

What’s the use case for starting an interactive shell from within
an interacive shell?

I will occasionally start a (nested) interactive shell when I am in the
middle of something non-trivial ~ complex and am relying on shell
history. The idea being that the new (nested) interactive shell will
have a separate (in memory) history for some less important tasks. Then
when I exit that (nested) interactive shell, I've only got one unrelated command in the history that I'm maintaining.

I know some people that will start a (nested) interactive shell so that
they can alter the environment to support things they need to be
different; SSH_AUTH_SOCK, or LD_PRELOAD to support a SOCKS proxy, or the
likes.

Sometimes it's more convenient to start a (nested) interactive shell
than it is to open another terminal emulator.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/23/21 12:01 PM, Jeremy Brubaker wrote:

For sure. I troll GitHub periodically for ideas but I'm always looking
for more.

I don't consider that to be /trolling/ in the "(please) don't feed the
torlls" sense. It may be /trolling/ in the sense of fishermen slowly
motoring around a body of water looking for a group of fish that they
like (the odds of getting a bite from).

I too do the latter. My comment on this thread is an example of that.
As is my last statement in this message.

Interesting. GNU coreutils paste treats no file argument as meaning
stdin. Apparantly FreeBSD 6 doesn't.

It may very well be the difference between GNU utilities and *BSD
utilities. There are many differences. This seems like another one of
them.

I mostly only use my dotfiles on my own system, so I haven't needed
to defensively add PATH entries, but that is a good point.

I used to copy my (then) Bash profile between about 750 systems that I supported at my old job. It was a mixture of Linux, AIX, Solaris,
HP-UX, OpenServer, UnixWare, and a scattering of BSD. Different systems
had different packages installed some of which needed their own custom
things; e.g. Oracle RDBMS, Tivoli Storage Manager (server), proprietary financial applications, etc. So ... suffice it to say that PATH was
anything but consistent.

I used my profile to normalize my interactions across that environment.
I would prepend my chosen directoriies to the PATH while still ...
defensively -- good description -- keeping the default PATH on the system.

I would even re-use my profile after su(do)ing to root on many of the
systems.

Suffice it to say that I had to be very careful, nay, defensive, on how
I configured my environment as I needed to support my /personal/ user
context and my /root/ instantiation context. Some systems I even needed
to support the context of the Oracle user.

I now do similar with Zsh on far fewer systems.

I used to have a bunch of PATH-manipulation functions I found
somewhere, but I realized I never used them. The only one I used was
called 'puniq' which I replaced with the one-liner because I only
needed to call it once.

I would be interested in seeing and learning from your PATH manipulation functions. That is if you have them handy and would be willing to share.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeremy Brubaker <jbrubake@orionarts.invalid> writes:

On 2021-11-22, Meredith Montgomery wrote:

The question is --- how do you manage your PATH? Thanks!

I use bash as my shell. My shell dotfiles are probably more complex than
they need to be, but I configure $PATH in ~/.env which is sourced by ~/.bash_profile.

At the end of ~/.env I run the following to remove duplicate entries
that may have crept in:

PATH=$(printf %s "$PATH" | awk -vRS=: '!a[$0]++' | paste -s -d:)

So, I can just add a new PATH entry to ~/.env and then source the file (assuming that everything in ~/.env is idempotent)

For what it's worth I use

function add-to-path {
[[ -d "$1" ]] || return
case ":${PATH/$1/}:" in
*::*) ;;
*) if [ "$2" = start ]; then PATH="$1:$PATH"; else PATH="$PATH:$1"; fi
esac
}

in bash. I can then

add-to-path "/usr/bin/mh"
add-to-path "$HOME/bin" start

and so on.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-24, Grant Taylor wrote:

On 11/23/21 12:01 PM, Jeremy Brubaker wrote:

For sure. I troll GitHub periodically for ideas but I'm always looking
for more.

I don't consider that to be /trolling/ in the "(please) don't feed the torlls" sense. It may be /trolling/ in the sense of fishermen slowly motoring around a body of water looking for a group of fish that they
like (the odds of getting a bite from).

I looked up the definition of /trolling/ just to make sure it was
accurate and that people weren't using it instead of a more correct
/trawling/. So, the latter sense was meant. :)

I mostly only use my dotfiles on my own system, so I haven't needed
to defensively add PATH entries, but that is a good point.

Suffice it to say that I had to be very careful, nay, defensive, on
how I configured my environment as I needed to support my /personal/
user context and my /root/ instantiation context. Some systems I even
needed to support the context of the Oracle user.

I *try* to do this, but as I only use various flavors of Linux (and
lately only Fedora and CentOS) I don't know how successful I am.

I now do similar with Zsh on far fewer systems.

I keep meaning to try zsh, but I don't want to add yet another
infinitely configurable package to my already long list. I hear good
things though.

I would be interested in seeing and learning from your PATH
manipulation functions. That is if you have them handy and would be
willing to share.

Here you go. I am not the original author although I likely tweaked them
a bit. No idea where I pulled them from originally.

#v+

# Usage: pls [<var>]
# List path entries of PATH or environment variable <var>.
pls () {
eval echo \$${1:-PATH} |tr : '\n';
}

# Usage: pshift [-n <num>] [<var>]
# Shift <num> entries off the front of PATH or environment var <var>.
# with the <var> option. Useful: pshift $(pwd)
pshift () {
local n=1
[ "$1" = "-n" ] && { n=$(( $2 + 1 )); shift 2; }
eval "${1:-PATH}='$(pls |tail -n +$n |tr '\n' :)'"
}

# Usage: ppop [-n <num>] [<var>]
# Pop <num> entries off the end of PATH or environment variable <var>.
ppop () {
local n=1 i=0
[ "$1" = "-n" ] && { n=$2; shift 2; }
while [ $i -lt $n ]
do eval "${1:-PATH}='\${${1:-PATH}%:*}'"
i=$(( i + 1 ))
done
}

# Usage: punshift <path> [<var>]
# Shift <path> onto the beginning of PATH or environment variable <var>. punshift () {
eval "${2:-PATH}='$1:$(eval echo \$${2:-PATH})'"
}

# Usage: ppush <path> [<var>]
ppush () {
eval "${2:-PATH}='$(eval echo \$${2:-PATH})':$1"
}

# Usage: puniq [<path>]
# Remove duplicate entries from a PATH style value while retaining
# the original order. Use PATH if no <path> is given.
#
# Example:
# $ puniq /usr/bin:/usr/local/bin:/usr/bin
# /usr/bin:/usr/local/bin
puniq () {
echo "$1" |tr : '\n' |nl |sort -u -k 2,2 |sort -n |
cut -f 2- |tr '\n' : |sed -e 's/:$//' -e 's/^://'
}

# Usage: prm <path> [<var>]
# Remove <path> from PATH or environment variable <var>.
prm () {
eval "${2:-PATH}='$(pls $2 |
grep -v "^$1\$" |tr '\n' :)'"
}

#v-

--
() www.asciiribbon.org | Jeremy Brubaker
/\ - against html mail | јЬruЬаkе@оrіоnаrtѕ.іо

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <snlnak$un9$1@dont-email.me>,
Jeremy Brubaker <jbrubake.362@orionarts.invalid> wrote:

On 2021-11-24, Grant Taylor wrote:

On 11/23/21 12:01 PM, Jeremy Brubaker wrote:

For sure. I troll GitHub periodically for ideas but I'm always looking
for more.

I don't consider that to be /trolling/ in the "(please) don't feed the
torlls" sense. It may be /trolling/ in the sense of fishermen slowly
motoring around a body of water looking for a group of fish that they
like (the odds of getting a bite from).

I looked up the definition of /trolling/ just to make sure it was
accurate and that people weren't using it instead of a more correct >/trawling/. So, the latter sense was meant. :)

Just to add some fuel to the fire...

Actually, both "troll" (as a verb) and "trawl" are terms from fishing (the sport of catching fish). The meaning of the two terms in the context of fishing is similar but distinct - but the differences are probably only of interest to fishermen (and not to Usenetters).

The term "troll" (as a verb) in the Usenet context seems to have derived
from either or both of these fishing terms. Furthermore, the term "troll"
(in the Usenet context) rarely means exactly the same thing to any two speakers. It has certainly gone throuh a lot of revision over the years.

In many online circles, "troll" (as a noun) just means anybody I don't
like. And "troll" (as a verb) means saying something I don't like/agree
with.

--
It's all Al Gore's fault...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-11-24, Kenny McCormack wrote:

In article <snlnak$un9$1@dont-email.me>,
Jeremy Brubaker <jbrubake.362@orionarts.invalid> wrote:

On 2021-11-24, Grant Taylor wrote:

On 11/23/21 12:01 PM, Jeremy Brubaker wrote:

For sure. I troll GitHub periodically for ideas but I'm always
looking for more.

I don't consider that to be /trolling/ in the "(please) don't feed
the torlls" sense. It may be /trolling/ in the sense of fishermen
slowly motoring around a body of water looking for a group of fish
that they like (the odds of getting a bite from).

I looked up the definition of /trolling/ just to make sure it was
accurate and that people weren't using it instead of a more correct >>/trawling/. So, the latter sense was meant. :)

Actually, both "troll" (as a verb) and "trawl" are terms from fishing (the sport of catching fish). The meaning of the two terms in the context of fishing is similar but distinct - but the differences are probably only of interest to fishermen (and not to Usenetters).

From https://grammarist.com/usage/trawl-troll/:

/Troll/ for means to patrol or wander about an area in search of
something. /Trawl/ for means to search through or gather from a
variety of sources.

As GitHub is a single source, I chose to use /troll/.

--
() www.asciiribbon.org | Jeremy Brubaker
/\ - against html mail | јЬruЬаkе@оrіоnаrtѕ.іо / neonrex on IRC

core error - bus dumped

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeremy Brubaker <jbrubake.362@orionarts.invalid> writes:

On 2021-11-23, Meredith Montgomery wrote:

Richard Kettlewell <invalid@invalid.invalid> writes:

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

If you are adding to $PATH in .bashrc, yes. IMHO, $PATH should only be
set once on login (through either .{,bash_}profile or .xsession. It
should *not* be set in .bashrc.

There is too much advice on dotfiles that simply says something along
the lines of "put everything in .bashrc and then source that from .bash_profile" which completely defeats the purpose of how dotfiles
*should* be used. And don't get me started on .xsession/.xinitrc.

That's in fact the bash default: .bash_profile sources .bashrc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

Richard Kettlewell <invalid@invalid.invalid> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

I know .bash_profile runs when I log in and it runs .bashrc when I run >>>> it interactively. To add a directory to the path, I usually

export PATH="/path/to/some/bin:$PATH"

If I add this to .bashrc, it will start adding more and more of the same >>>> directories to the path if I run new interactive shells, so I always add >>>> them to .bash_profile.

What’s the use case for starting an interactive shell from within an
interacive shell?

You know, say, tail -f /var/log/messages just to monitor it while you
work on something else in some other shell.

I don’t see where the recursive shells come from in that case. I might
run tail in the background, or more likely in a completely separate
terminal.

What's a recursive shell?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Meredith Montgomery <mmontgomery@levado.to> writes:

Jeremy Brubaker <jbrubake.362@orionarts.invalid> writes:

On 2021-11-23, Meredith Montgomery wrote:

Richard Kettlewell <invalid@invalid.invalid> writes:

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

If you are adding to $PATH in .bashrc, yes. IMHO, $PATH should only be
set once on login (through either .{,bash_}profile or .xsession. It
should *not* be set in .bashrc.

There is too much advice on dotfiles that simply says something along
the lines of "put everything in .bashrc and then source that from
.bash_profile" which completely defeats the purpose of how dotfiles
*should* be used. And don't get me started on .xsession/.xinitrc.

That's in fact the bash default: .bash_profile sources .bashrc.

.bash_profile sources .bashrc only if you write
. .bashrc
or
source .bashrc
in your .bash_profile file. The contents of .bash_profile and .bashrc
are controlled by the user, not by bash.

bash automatically sources certain files on startup (the rules are in
the bash documentation, and I won't attempt to summarize them). What
those sourced files do is entirely up to you.

Some operating systems will set up default .bashrc and .bash_profile
files when creating a new user account.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/24/21 11:16 AM, Jeremy Brubaker wrote:

/Troll/ for means to patrol or wander about an area in search of
something. /Trawl/ for means to search through or gather from a
variety of sources.

So ... do you trawl for means to enhance your trolling?



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/24/21 8:56 AM, Jeremy Brubaker wrote:

I *try* to do this, but as I only use various flavors of Linux (and
lately only Fedora and CentOS) I don't know how successful I am.

I think making the effort counts here.

I keep meaning to try zsh, but I don't want to add yet another
infinitely configurable package to my already long list. I hear good
things though.

;-)

Here you go. I am not the original author although I likely tweaked
them a bit. No idea where I pulled them from originally.

Thank you.

I'll spend some time looking at these.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/24/21 2:10 PM, Meredith Montgomery wrote:

That's in fact the bash default: .bash_profile sources .bashrc.

Is that the /Bash/ default?

Or is it the default contents in the .bash_profile that some
distributions ship? Meaning that it's the /distribution/ default?



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Meredith Montgomery <mmontgomery@levado.to> writes:
[...]

What's a recursive shell?

A shell process invoked from another shell process, for example by
typing "bash" or "bash -l" at a bash command line.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/23/21 9:37 AM, Grant Taylor wrote:

That works in Zsh and Bash on contemporary systems.  However I had to slightly modify it for an old FreeBSD 6.x system that I have access to.

  PATH=$(printf %s ${PATH} | awk -vRS=: '!a[$0]++' | paste -s -d: -)

I recently put together the following method using pure Zsh built-ins to achieving the same result. (I have no idea if Bash has counterparts.)

TEMPPATH=(${(s,:,)PATH}) # Explode the PATH into an array. UNIQPATH=(${(u)TEMPPATH}) # Create a unique array of just the first
# occurrence of members.
PATH=${(j,:,)UNIQPATH} # Create a new PATH string by joining
# UNIQPATH members.
export PATH # Because $REASONS ....
unset TEMPPATH UNIQPATH # Clean up after ourselves.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:

Jeremy Brubaker <jbrubake.362@orionarts.invalid> writes:

On 2021-11-23, Meredith Montgomery wrote:

Richard Kettlewell <invalid@invalid.invalid> writes:

My additions seem to be in .bashrc, but the default .profile adds a
couple of things too. It also runs .bashrc.

But then if you open a new xterm window, say, I think it will re-add
your additions, will it not?

If you are adding to $PATH in .bashrc, yes. IMHO, $PATH should only be
set once on login (through either .{,bash_}profile or .xsession. It
should *not* be set in .bashrc.

There is too much advice on dotfiles that simply says something along
the lines of "put everything in .bashrc and then source that from
.bash_profile" which completely defeats the purpose of how dotfiles
*should* be used. And don't get me started on .xsession/.xinitrc.

That's in fact the bash default: .bash_profile sources .bashrc.

.bash_profile sources .bashrc only if you write
. .bashrc
or
source .bashrc
in your .bash_profile file. The contents of .bash_profile and .bashrc
are controlled by the user, not by bash.

bash automatically sources certain files on startup (the rules are in
the bash documentation, and I won't attempt to summarize them). What
those sourced files do is entirely up to you.

Some operating systems will set up default .bashrc and .bash_profile
files when creating a new user account.

That makes sense. Thanks for the correction.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Meredith Montgomery <mmontgomery@levado.to> writes:
[...]

What's a recursive shell?

A shell process invoked from another shell process, for example by
typing "bash" or "bash -l" at a bash command line.

Oh, I see. Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

On 11/24/21 2:10 PM, Meredith Montgomery wrote:

That's in fact the bash default: .bash_profile sources .bashrc.

Is that the /Bash/ default?

Or is it the default contents in the .bash_profile that some
distributions ship? Meaning that it's the /distribution/ default?

Second option. See Keith's answer in the thread. I jumped to
conclusions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/30/21 6:09 PM, Meredith Montgomery wrote:

Second option. See Keith's answer in the thread. I jumped to
conclusions.

*nod*

Thank you for the clarification.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <so3hds$k2r$1@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote:

On 11/23/21 9:37 AM, Grant Taylor wrote:

That works in Zsh and Bash on contemporary systems.  However I had to
slightly modify it for an old FreeBSD 6.x system that I have access to.
PATH=$(printf %s ${PATH} | awk -vRS=: '!a[$0]++' | paste -s -d: -)

I recently put together the following method using pure Zsh built-ins to achieving the same result.

*SKIP*

TEMPPATH=(${(s,:,)PATH})
UNIQPATH=(${(u)TEMPPATH})
export PATH
unset TEMPPATH UNIQPATH

How about this then:

path=( ${(u)path} )

Case is significant, one incantation, even less portable.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/1/21 5:03 AM, Eric Pozharski wrote:

How about this then:

path=( ${(u)path} )

I like it.

Case is significant, one incantation, even less portable.

I didn't think about the difference of PATH being a string and path
being an array until I read your comment.

I've now updated my ~/.zshrc file. :-)

Thank you.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

On 12/1/21 5:03 AM, Eric Pozharski wrote:

How about this then:
path=( ${(u)path} )

I like it.

Case is significant, one incantation, even less portable.

I didn't think about the difference of PATH being a string and path
being an array until I read your comment.

I've now updated my ~/.zshrc file. :-)

Thank you.

Yes, this is a zsh-specific feature, apparently borrowed from csh.

From the zshparam(1) man page:

In cases where there are two parameters with an upper- and
lowercase form of the same name, such as path and PATH, the
lowercase form is an array and the uppercase form is a scalar
with the elements of the array joined together by colons.
These are similar to tied parameters created via `typeset -T'.
The normal use for the colon-separated form is for exporting to
the environment, while the array form is easier to manipulate
within the shell. Note that unsetting either of the pair
will unset the other; they retain their special properties
when recreated, and recreating one of the pair will recreate
the other.

zsh has several paired built-in variables like this.

csh (and tcsh) does this for $path and $PATH, but in a more ad-hoc
manner.

bash doesn't have this feature.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)