I want to add my own ~/bin directory to the beginning of the PATH

[Moderator BobC]

Helpful

Up

0

::

I added $HOME/bin to the front of the path in slim.conf and changed $HOME/bin so that it takes root authority to write there. That way it gets included in my $HOME backup, but isn’t totally easy to corrupt.

Thanks for the ideas/suggestions.

[Moderator Brian Masinick]

Helpful

Up

0

::

That should be fine for your purposes.

Hope it works out well and you are able to implement several of your ideas.

--
Brian Masinick

[Moderator BobC]

Helpful

Up

0

::

Yes, its pretty much working. One thing it does weird is that if in under sudo or su it isn’t in the path. I haven’t decided if that is actually a benefit or not. My changes are typically minor tweaks, and usually not to major programs, but I really would like to keep them separate. I installed a program called meld that makes it easy to merge versions of a program.

[Anonymous]

Helpful

Up

0

::

I added $HOME/bin to the front of the path in slim.conf and
[..]
weird is that if in under sudo or su it isn’t in the path

The “sane defaults” of the as-shipped sudoers policy are “weird”, eh?
Oof.
“There is nothing so foolproof that it can stop a DETERMINED fool.”

I want to put my tweaked versions of programs in a different directory in front of /usr/local/bin so that my version runs and doesn’t get overlaid by an update.

Bob, consider the following:

You create a root-owned /z/ top-level directory and place your modded wallpaper.py there.
You set PATH=/z:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
Although an “apt update wallpaper-antix” operation will not overwrite your modded scriptfile…

…along comes Suzie, who launches the controlCenter app and clicks “Choose Wallpaper”.
Oops, antixcc.sh explicitly calls “/usr/local/bin/wallpaper.py”, therefore your modded scriptfile is bypassed.

I want [..] so that my version runs and doesn’t get overlaid by an update.

Okay, was foggy previously but I now understand your goal.
I’ll followup to post a “correct” solution, one which employs the “dpkg-divert” command.
In the meantime, man dpkg-divert

[Moderator BobC]

Helpful

Up

0

::

No, I never heard of that before. I will look at it.

Thanks much

[Anonymous]

Helpful

Up

0

::

It’s an obscure utility which has been available in debian (dkpg) since way back in 1996,
but is seldom discussed outside the BlackArts realm of the debian package maintainers’ mailing list(s).

Prior to now, I’ve only used it infrequently, and each time I’ve scrabbled to find my notes
trying to jog my memory regarding its arcane syntax.

Any user (non-sudo) can “dpkg-divert –list” and inspect the diversions currently in place on the system
(grrrrrrrrr, dash dash list, not longdash list, the infernal forum sofware still mangles that)
but that doesn’t provide insight into when, how, or why each of the diversions was enacted.

When reading the manpage, focus on the “local” option.
Use of that option provides exactly what is needed to meet the goal of
“I want [..] so that my version runs and doesn’t get overlaid by an update.”

I’m writing a bash wrapper script so that we, as local sysadmins, can easily create and manage diversions.

takeover </path/to/some/file>
vs
dpkg-divert –local –add –divert <somefile>/diverted/$(basename <somefile>) <somefile>

takeover -r </path/to/some/file>
(((( mnemonic ~= “relinquish” ))))
vs
dpkg-divert –local –remove –divert <somefile>/diverted/$(basename <somefile>) <somefile>

takeover -s
(((( mnemonic ~=showall takeovers, plural )))
vs
dpkg-divert –list
(noted: the output –listpackage is unhelpful for our use;
it doesn’t convey whether <somefile> is the object, or subject, of a given rule)

For most, or all, other related diversion operations (which will be comparatively infrequent)
we might as well (I’m proposing) just resort to typing the native dpkg-divert command+options.

We (or at least I) will avoid using the inbuilt –rename option. Instead, the “takeover” command will utilize a convention of placing the most recent pkg-provided ORIG version of a diverted file, preserved for reference, in a child subdirectory <originalLocation>/diverted/ (most recent, meaning,
replace//overwrite operations performed during package updates will, per corresponding rule, target the copy residing in /diverted/ )

The functionality of the “takeover” command that I’ve described so far in this post is in place, is working.
I’m currently testing & refining it to accommodate various potential scenarios.
For example, if you’re attempting to add a rule targeting a file which does not exist:
is the non-existent pathstring a typo… or maybe your intent is to pre-emptively create a rule targeting a file which is provided by a not-currently-installed (not-yet-installed) package?

~~~~~~~~~~~~~~~~~~~~~~~~~~~

An (optional) companion script, “divertswatch”, suitable for launching via a line added to ~/.desktop-session/startup will parse the current diversions list and set an inotifywatch trigger for each of the /diverted/ directories. (prerequisite: sudo apt install inotify-tools)(76kb). Cheap — negligible memory overhead — it will popup a yad dialogbox (new activity detected in: /path/to/a/watched/diverted/) whenever an apt update // upgrade // install // remove operation affects (the /diverted/ “orig” copy of) a file protected by one of your local dpkg-divert rules.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

You mentioned “meld”. (in faint pencil) I had added to the TODO list:
takeover -m <somefile>
^—> blahblah; shift; meld $1 /diverted/$1
but quickly backed away from tackling the added complexity of determining when vs when not to drop priviledges (via adding su, or runuser, into the meld launchstring). (note: “takeover”, er the underlying dpkg-divert command, must run with elevated permissions in case you intend to add or remove rules.) Instead, you could just define in .bashrc an alias for “meld $1 /diverted/$1” to be prefaced by sudo or gksu, as needed, on a per-each-launch basis.

[Moderator Brian Masinick]

Helpful

Up

0

::

@Skidoo:
I like the idea of the takeover script. Are you going to publish it here, add it to the tools (or both)?

If it’s not “public”, I’d certainly be interested in it. Though I do not do anywhere near as much fooling around with the system, utilities, or tools as I’ve done in the past, since I have (in the distant past), been a member of an operating system tools development and maintenance team, I still enjoy this stuff from time to time.

Anyway I appreciate the conversation, the ideas, and the experimentation. This is what can make collaborative software efforts interesting and fun, at least to an old geek like me! Thanks again!

--
Brian Masinick

[Moderator BobC]

Helpful

Up

0

::

I checked, and only have 1 modified program left now. All the rest are now built into antiX 19 🙂

I looked at the manual and will give the dpkg-divert a try coming from a test machine loaded with antiX19b2 or b1.

Thanks for the idea. I’ll let you know how it works and if you like I’ll add a couple more so I can beta test your script for you.

[Author]

Posts