Requesting update file for PATH (21.3 Wildflower Xfce)(and now mx25)

[figueroa]

The file .profile is read on startup if your computer boots to a shell prompt (login shell). it's not read for a GUI window terminal shell.

Code: Select all

$ head -1 .profile
# ~/.profile: executed by the command interpreter for login shells.

If the user wants their personal home directory bin in a terminal shell from the GUI, add the following path invocation from .profile into the end of .bashrc after any other PATH directives:

Code: Select all

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

This simple solution has pitfalls and may result in the $HOME/bin path being set twice if logging in remotely (ssh shell) or launching multiple instances of bash in a terminal shell.

A more complete solution which I adapted for my own use was found on StackExchange here: https://superuser.com/a/1781683/1858017 by Oleg Poltoratskii. Mainly, we don't want the script to modify our .bashrc and we need to check that the $HOME/bin really exists . I put the following lines in both .profile at the end replacing the existing invocation, or adding to .bashrc after the sbin path invocation:

Code: Select all

if [ -d "$HOME/bin" ] ; then

	if [[ ":$PATH:" != *":$HOME/bin:"* ]]; then \
	PATH=$HOME/bin:$PATH;
	fi

fi

Here the first "if" checks to ensure that a user actually has a bin subdirectory in their home directory. The second "if" checks to see if the existing PATH environmental variable already contains $HOME/bin set. The invocation in .profile is used for login shells and is not duplicated when bash runs. For terminal shells, the invocation on .bashrc is used but does not result in duplication if additional terminal shells are opened.

Your mileage may vary, but I don't believe these lines will give you any trouble. Developed and working in MX-18.3 and MX-21.3.

[Eadwine Rose]

Eadwine Rose

Well, I can still hope for a responsible way of thinking, requesting and answering in the forum culture anyway.

Thanks so much, that came across nice and disrespectful.

[Jakob77]

The file .profile is read on startup if your computer boots to a shell prompt (login shell). it's not read for a GUI window terminal shell.

Code: Select all

$ head -1 .profile
# ~/.profile: executed by the command interpreter for login shells.

If the user wants their personal home directory bin in a terminal shell from the GUI, add the following path invocation from .profile into the end of .bashrc after any other PATH directives:

Code: Select all

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

This simple solution has pitfalls and may result in the $HOME/bin path being set twice if logging in remotely (ssh shell) or launching multiple instances of bash in a terminal shell.

A more complete solution which I adapted for my own use was found on StackExchange here: https://superuser.com/a/1781683/1858017 by Oleg Poltoratskii. Mainly, we don't want the script to modify our .bashrc and we need to check that the $HOME/bin really exists . I put the following lines in both .profile at the end replacing the existing invocation, or adding to .bashrc after the sbin path invocation:

Code: Select all

if [ -d "$HOME/bin" ] ; then

	if [[ ":$PATH:" != *":$HOME/bin:"* ]]; then \
	PATH=$HOME/bin:$PATH;
	fi

fi

Here the first "if" checks to ensure that a user actually has a bin subdirectory in their home directory. The second "if" checks to see if the existing PATH environmental variable already contains $HOME/bin set. The invocation in .profile is used for login shells and is not duplicated when bash runs. For terminal shells, the invocation on .bashrc is used but does not result in duplication if additional terminal shells are opened.

Your mileage may vary, but I don't believe these lines will give you any trouble. Developed and working in MX-18.3 and MX-21.3.

Thank you for the code but I don't think you really understand what it is about.
As a new user in MX I was frustrated because it was difficult to make PATH work correctly to it's full extend.
But I am not having any problems with it anymore.
I have a backup of xinitrc so I just restore the file.
The work I do here is not for me but for MX and new users.
And I hope not I am wrong when I take it for granted that we all want MX to make a good impression on new users.


Have you tested if the code you bring here actually works from the desktop in a launcher.?
I doubt it, and that is one of the problems I see in this. Too many half solutions.
However if the file was to be sent out in an update and there was no limit to details, some of your code could perhaps prevent a couple of users from getting ~/bin twice in PATH.

[Jakob77]

Okay, as a kind of status from here this is ~/.config/xfce4/xinitrc the way it looks on my computer today:

Code: Select all

#!/bin/sh
# This file: ~/.config/xfce4/xinitrc
# Script for setting user PATH in MX 21.3 Xfce
# This file might later be overwritten by MX update or a MX-tool.
# You can read more here: https://forum.mxlinux.org/viewtopic.php?t=75245
# In order to work, this script needs to be in the right folder and have permission to run like a program
# ( chmod +x ~/.config/xfce4/xinitrc  or  chmod 755 ~/.config/xfce4/xinitrc or Thunar right click file -> prop -> perm )



# if unlocked, the 3 lines below in a whole includes ~/binhomeautomation in PATH only if the folder exist 
	if [ -d "$HOME/binhomeautomation" ] ; then
	PATH="$HOME/binhomeautomation:$PATH"
	fi
# If the 3 lines above this line are unlocked and ~/binfirst is not created
# then ~/binhomeautomation will be included first in PATH 
# This folder is just a preparation and will likely be changed later. 



# if unlocked, the 3 lines below in a whole includes ~/binfirst in PATH only if the folder exist 
	if [ -d "$HOME/binfirst" ] ; then
	PATH="$HOME/binfirst:$PATH"
	fi
# If the 3 lines above this line are unlocked ~/binfirst will be included first in PATH 
# Mostly for testing.



# if unlocked, the 3 lines below in a whole includes ~/binpre in PATH only if the folder exist
	if [ -d "$HOME/binpre" ] ; then
	PATH="$PATH:$HOME/binpre"
	fi
# if the 3 lines above this line are unlocked ~/binpre will be included before ~/bin in PATH.
# So if you have two scripts with similar names in the two folders, only the one in ~/binpre will be found and executed.
# The folder is sometimes created for development and test purposes.



# if unlocked, the 3 lines below in a whole includes ~/bin in the end of PATH only if the folder exist 
	if [ -d "$HOME/bin" ] ; then
	PATH="$PATH:$HOME/bin"
	fi
# if the 3 lines above this line are unlocked ~/bin will be included last in PATH 
# ~/bin is the default and most normal folder name for user scripts.
# If you by accident make a script with the same name as a system command, your script will not block the system here
# because the system command file is in a folder that comes before ~/bin in PATH


	exec /etc/xdg/xfce4/xinitrc

Yes, there is too much text and maybe you want other names but this is more about the folders and getting all the relevant stuff on the table.



What is the folder "/.local/bin" we see in ~/.profile supposed to be used for.?
Should I also put that one in the script.?


I have not seen any response about ~/binhomeautomation so I just put it in.


And then there are these two folders that the MX-bash-tool adds to PATH in Terminal:

Code: Select all

:/sbin:/usr/sbin

Should they also always be in PATH when a command is executed from a launcher on the Desktop.?
If so I guess they also have to be included in xinitrc and removed from the MX-tool.

More loose ends.? :-)

[Jakob77]

Yes, I forgot ~/binpost
It is more likely to be used by me than ~/binpre because my editor script is hard coded for ~/bin
So instead of putting a script copy in ~/binpre and work on it there I will prefer to stay in bin and put a backup in ~/binpost
So ~/binpost has now been added to the script.


About "~/.local/bin" (the one you can read about in the file ~/.profile)
I don't know what it is for, but there has to be a meaning, and I can't imagine that it can do anything but good to put it in the script. So it is also added now.







I am waiting for the developers to push back but if they don't I now only have this loose end left:

The two folders that the MX-bash-tool adds to PATH in Terminal:

Code: Select all

:/sbin:/usr/sbin

I don't know if I am right but I have got the impression that those folders are only sometimes needed for sudo commands and nothing else.
If that is the case I don't need them in this script because I would never run a sudo script from a launcher. I haven't even tested it. In my world both commands and scripts with sudo belongs in terminal where the user can read the output.
However maybe others has another policy, and there can be things I don't know, so without a blessing from the developers I feel too unsure to make a script suggestion on this one.





~/.config/xfce4/xinitrc with my last update for further testing:

Code: Select all

#!/bin/sh
# This file: ~/.config/xfce4/xinitrc
# Script for setting user PATH in MX 21.3 Xfce
# This file might later be overwritten by MX update or a MX-tool.
# You can read more here: https://forum.mxlinux.org/viewtopic.php?t=75245
# In order to work, this script needs to be in the right folder and have permission to run like a program
# ( chmod +x ~/.config/xfce4/xinitrc  or  chmod 755 ~/.config/xfce4/xinitrc or Thunar right click file -> prop -> perm )



# if unlocked, the 3 lines below in a whole includes ~/binhomeautomation in PATH only if the folder exist 
	if [ -d "$HOME/binhomeautomation" ] ; then
	PATH="$HOME/binhomeautomation:$PATH"
	fi
# If the 3 lines above this line are unlocked and ~/binfirst is not created
# then ~/binhomeautomation will be included first in PATH 
# This folder is just a preparation and will likely be changed later. 



# if unlocked, the 3 lines below in a whole includes ~/binfirst in PATH only if the folder exist 
	if [ -d "$HOME/binfirst" ] ; then
	PATH="$HOME/binfirst:$PATH"
	fi
# If the 3 lines above this line are unlocked ~/binfirst will be included first in PATH 
# Mostly for testing.



# if unlocked, the 3 lines below in a whole includes ~/binpre in PATH only if the folder exist
	if [ -d "$HOME/binpre" ] ; then
	PATH="$PATH:$HOME/binpre"
	fi
# if the 3 lines above this line are unlocked ~/binpre will be included before ~/bin in PATH.
# So if you have two scripts with similar names in the two folders, only the one in ~/binpre will be found and executed.
# The "~/binpre" folder name can be changed if wanted. The folder is sometimes created for development and test purposes.



# if unlocked, the 3 lines below in a whole includes ~/bin in the end of PATH only if the folder exist 
	if [ -d "$HOME/bin" ] ; then
	PATH="$PATH:$HOME/bin"
	fi
# if the 3 lines above this line are unlocked ~/bin will be included last or almost last in PATH 
# ~/bin is the default and most normal folder name for user scripts.
# If you by accident make a script with the same name as a system command, your script will not block the system here
# because the system command file is in a folder that comes before ~/bin in PATH



# if unlocked, the 3 lines below in a whole includes ~/binppost in PATH only if the folder exist
	if [ -d "$HOME/binpost" ] ; then
	PATH="$PATH:$HOME/binpost"
	fi
# if the 3 lines above this line are unlocked ~/binpost will be included after ~/bin in PATH.
# ~/binpost can for instance be used for testing and backing up scripts you want to edit in ~/bin



# if unlocked, the 3 lines below in a whole includes ~/.local/bin in PATH only if the folder exist
	if [ -d "$HOME/.local/bin" ] ; then
	PATH="$PATH:$HOME/.local/bin"
	fi
# if the 3 lines above this line are unlocked ~/.local/bin will be included last or almost last in PATH.
# For instance the MX-tool "Bash Config" can still add more folders to PATH in Terminal
# ~/.local/bin is for preparation



	exec /etc/xdg/xfce4/xinitrc

EDIT a week later:

The text is still in the same style. Too much and it makes in my opinion the script a bit of a hybrid between a temporary file for users to copy now, and a file ready to be installed by MX.
I can come the last chapter closer if it is relevant.
But I do think this script as an exception from many other scripts is calling for some help to the user.
If it is against a strong policy it can be minimized by links.



I have also found some more thrilling information about xinitrc that I find important to be added:

https://forum.xfce.org/viewtopic.php?pid=73837#p73837

With xinitrc, you can set any environment variables or even run programs if you want to.

[Jakob77]

2025 - follow up



Well now a couple of years later I can admit I got a little carried away when I was putting code and explanations in the script.
It was a sort of sorry attempt to cover more inspiration for the developers.

However if there is going to be a little advice or a link to some advice about environment variables that will also be up to the developers. I am all for.! _



And then the job will be completely done.?
No, I guess it will never be, especially if it continues with the same speed. lol




This code is not tested and there might be a whole lot of implications I don't have a clue about but I am sure it will be understood what I am aiming for when I want it to be added:

Code: Select all

	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	PATH="$PATH:$HOME/Live-usb-storage/bin"
	fi

If you have a Live USB and want to add or change a script, then you can just rename it and put it in "~/Live-usb-storage/bin" from where it can be used and will be saved. The option will always be with you on any full featured snapshot in case you need it.

What do you think.?
I am all for.! _

[Jakob77]

This code is not tested and there might be a whole lot of implications I don't have a clue about but I am sure it will be understood what I am aiming for when I want it to be added:

Code: Select all

	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	PATH="$PATH:$HOME/Live-usb-storage/bin"
	fi

If you have a Live USB and want to add or change a script, then you can just rename it and put it in "~/Live-usb-storage/bin" from where it can be used and will be saved. The option will always be with you on any full featured snapshot in case you need it.

Now I have been testing the code a little, and it looks like it works.
I have to make a Live USB for every test so it is a little slow, and therefore I decided to try more in the first round.
That made me add this code to xinitrc:

Code: Select all

	if [ -d "$HOME/Live-usb-storage" ] ; then
	mkdir -p "$HOME/Live-usb-storage/bin"
	fi


	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	PATH="$PATH:$HOME/Live-usb-storage/bin"
	fi


	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	chmod 700 ~/Live-usb-storage/bin
	fi

And oh my goodness it all worked, so now when I boot up on a full featured USB Live disk already the first time I will automatically have created "$HOME/Live-usb-storage/bin" completely ready for use with PATH and permissions.
I am so amazed and can't see a risk, so I just implemented it right away in my system, and I guess I will keep it but at the moment I have no overview for an opinion about how much of it can be a good idea to implement in MX25




The most important in this post could be to bring attention to "chmod" if it is valid code.
It looks like xinitrc gives us a chance to automatically make permissions right and safe for any user directory at every boot up.
It can also be implemented in another startup script and maybe I will choose to do that instead.
Or maybe it already exists in a third place in MX (no need for a double).?
I am seriously thinking about also adding lines like these to xinitrc just for safety:

Code: Select all

	if [ -d "$HOME/.thunderbird" ] ; then
	chmod 700 ~/.thunderbird
	fi

	if [ -d "$HOME/.mozilla" ] ; then
	chmod 700 ~/.mozilla
	fi

	if [ -d "$HOME/.bin" ] ; then
	chmod 700 ~/.bin
	fi

[Nokkaelaein]

I am so amazed and can't see a risk, so I just implemented it right away in my system, and I guess I will keep it but at the moment I have no overview for an opinion about how much of it can be a good idea to implement in MX25

In order to be a good idea to implement as a default, it needs to be considered safe, meaning that it really works in all target use cases in a safe manner. Consider that the Live-usb-storage directory can reside on a FAT32, exFAT or NTFS filesystem, so how are you handling the POSIX type of executable permissions on the files you place inside ~/Live-usb-storage/bin then? Even if that directory is added to the path, the files themselves need to be set executable to work the way you intend.

Personal opinion: I think this whole "let's add stuff to the default path" thing you've been running for something like two years already... is misunderstanding the point of safe and sensible defaults, and what flexibility means in a context of an operating system. Flexibility doesn't mean that there are wild defaults "just in case" for the users who just might want to use them. For the users who really might want to do this, it's not like one distro is more flexible than the other because someone included a cludge to add something to the path from a USB drive on every freakin' system.

[atomick]

Quite a garden path of issue depth discussion and attempts to try and reveal better code. " As the various distro take on their on affect " much is consider to be linux environment 101. Yet as some create distro /etc/environment with the system path being set.

there is an /etc/bash.bashrc as a pre-Set config as well as user environment check addin and tag on to the all system path statement.

Customization at one time sourced ~/.profile with a follow up to customization also at the ~/.bashrc as to being the personalized to custom path for personal check this that at a find and or execution of script. Habit for some cd to development directories
or ~/.bin or ~/.local/bin view the .profile carefully this checks if personalize add to default being the " bin " folder and its personal placement this code can be changed to fit if desire. Some might create a myScripts devo directory in another place of
/home/meUser has been odd time if one just encrypts their home folder can get locked out of their account (hence some create test accounts and or back account) some encrypt Crypto-LUKS the whole drive. in form does not really matter you unlock the whole drive at system boot. Still vulnerable.

Not to go off course 1st off again so much is done in Shell. or choice of shell each also have their attribute to getting it straight and correct per how one may customize their Rig and desktop experience. Bash does cover environment but ....

Code: Select all

    open a shell   xfce4-terminal  or what ever flavor  I install Konsole is one my more fav.   Type

echo $PATH  - this will reveal the all inclusive path of system and personal set environment directory PATH all to find things.  When you open a shell or terminal app.

PATH=$PATH:/dir1:/dir2 .... to all   to add too this best place in my honest placement is in ~/.bashrc   Can do it again you have to look at the code and see pretty much in the middle of the ~/.bashrc   is 

echo $PATH | grep -Eq "(^|:)/sbin(:|)"     || PATH=$PATH:/sbin
echo $PATH | grep -Eq "(^|:)/usr/sbin(:|)" || PATH=$PATH:/usr/sbin

if [ -f ~/.bash_aliases ]; then
    source ~/.bash_aliases
export PATH="$PATH:/home/$USER:/myDir1:/mDir2:/myLive"  
 OR
export PATH="$PATH:/home/atomick/myDri1:/myDir2:/bin/.local/bin2/scripts;/myBigDrvE/scripts "      #my customized,   Note I can add any directory label I wish to my home there are Butts! myBigDrvE is a m2 mount point for perma access.
fi

I changed my own personal simply to show this is taken out of .bashrc one major caveat for hack is and was at one time to end the PATH="$PATH:/home/atomick:/.local/myscripts:/media/atomick/myLive: " followed up with
export $PATH

Note what I was going to express is DO NOT end the statement with a Colon : see I let a pluggable device I may use labeled myLive which I pop in an out of a USB port when UDEV detects so , it shall be avail to a search and my custom.
Aliases can be a super benefit this is also done in a section ~/.bashrc as well or can be a single additional file ~/.bash_aliases
here I can set an alias to a specific even soft link it so when its plugged in an out I can cd to it when.

Code: Select all

  
alias mS='cd /media/atomick/myLive/myscripts;pwd' 

# once set I do not req reboot nor logout  write out changes and resource it via your .bashrc

source .bashrc
and now 
cd /mS
I am there. 

This example Note /media is for portable plugin devices only create a mount point if it is a special SSD you use, again practice and research
https://www.gnu.org/software/bash/ # check here for other resources , the primary bash.doc should be included yet are not so here check search Bash Environment or all out Browser search "best practice setting bash environment"
or "setting bash PATH" "customizing bash environment" a great deal can be learned if so desire to patiently do so. use of an alias statement can make this process of speed value.

if using a special SSD on say a USB sata adaptor - this leads to setting a mount point and learning to mount and umount device - note not "un-mount" the n is not there for dismounting a device. This can provide security for your self doing this.
ie: reason "antiX" is another trim down flavor of linux Run as MX can also Run if installed to a large Flash Drive. Few installs allow to FLASH oppose to just Spinner/ssd/m2.nvme type drives. setting a script to mount and also adding to PATH
same time can be rewarding.

Advance Bash Scripting Guide can also provide more to what is missing per, without going to vast detail remember the PWD / pwd command line Present Working Directory
to know command line in Linux / *NIX is so very powerful odd 1, 2 cmd can reap what 1000s of code lines to create "Those Windows Like Gui's " and can be your friend as to learn yes tad steep learn curve get to know Web searching can tackle many a question. Best to try cd to your correct location where pwd copy this path and add it to the ~/.bashrc as shown one last you can add it direct to the PATH statement and test it. log out or Reboot will lose this entry

Code: Select all

   echo $PATH
PATH="$PATH:/media/mrUser/myLive/myarchive;/myBigDrv/Pics:/myBigDrv/Games"
export $PATH
pwd       #check and see if all match  your good.  suggest yes you can work it at /etc/environment  or /etc/bash.bashrc  copy them prior edit or only do it in your own .bashrc .zshrc .fishrc  as few exampe Fish really has another method 

hope to share some hints tips and queues. Cheers.

[DukeComposed]

Now I have been testing the code a little, and it looks like it works.

Code: Select all

	if [ -d "$HOME/Live-usb-storage" ] ; then
	mkdir -p "$HOME/Live-usb-storage/bin"
	fi


	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	PATH="$PATH:$HOME/Live-usb-storage/bin"
	fi


	if [ -d "$HOME/Live-usb-storage/bin" ] ; then
	chmod 700 ~/Live-usb-storage/bin
	fi

This is duplicative and inelegant. Why would the check for the ./bin directory need to be performed twice? Instead:

Code: Select all

if [ -d "$HOME/Live-usb-storage/bin" ] ; then
  PATH="$PATH:$HOME/Live-usb-storage/bin"
  chmod 700 ~/Live-usb-storage/bin
fi

Worse, if the Live-usb-storage directory exists, mkdir(1) will always be run, whether ./bin already exists or not. Better to create it only when it doesn't already exist.

Code: Select all

TARGET=$HOME/Live-usb-storage
TARGETBIN=$TARGET/bin
if [ -d ${TARGET} ] ; then
  if [ ! -d ${TARGETBIN} ] ; then
	mkdir ${TARGETBIN} && chmod 0700 ${TARGETBIN}
  fi
fi

The -p flag to mkdir(1) is superfluous because you know you're only creating one subdirectory in a path that already exists. You know this because you already tested for it.