I'm not good with command lines or servers. But I needed to configure for work a AMI of EC2 AWS with LINUX So I've installed a lot of stuff, moved a lot of stuff around and then I realized that sudo was not behaving normally. Before, when I typed sudo, I would become a root user right away. Now when I type sudo, I get the command instructions (as if I had typed --help) [ec2-user@ip-172-31-33-121 ~]$ sudo usage: sudo [-D level] -h | -K | -k | -V usage: sudo -v [-AknS] [-D level] [-g groupname|#gid] [-p prompt] [-u username|#uid] usage: sudo -l[l] [-AknS] [-D level] [-g groupname|#gid] [-p prompt] [-U username] [-u user name|#uid] [-g groupname|#gid] [command] usage: sudo [-AbEHknPS] [-r role] [-t type] [-C fd] [-D level] [-g groupname|#gid] [-p prompt] [-u user name|#uid] [-g groupname|#gid [VAR=value] [-i|-s] [] usage: sudo -e [-AknS] [-r role] [-t type] [-C fd] [-D level] [-g groupname|#gid] [-p prompt] [-u user name|#uid] file . To become a root user *now* on my server I have to type sudo su. But once I do that all the commands stop working! [root@ip-172-31-33-121 ec2-user]# yum bash: yum: command not found I've read somewhere it could be a problem with my PATH, and I remember I did changed something on the PATH variable while doing some installations but I can't remember exactly what and why, I think it was when I was trying to install node.js or npm, anyway I'm not sure how to restore my PATH and if that is really the problem *I tried to restore my path, but I don't know how it was before, so or I restored it and it isn't the problem or I didn't really restored it. Output of echo $PATH: [root@ip-172-31-33-121 ~]# echo $PATH /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/local/bin:/opt/aws/bin:/root/bin But I'm really new with this server config stuff, I have no idea if this is right... or wrong When I run sudo -i: [ec2-user@ip-172-31-33-121 ~]$ sudo -i -bash: id: command not found -bash: tty: command not found [root@ip-172-31-33-121 ~]# uname -a Linux ip-172-31-33-121 3.14.44-32.39.amzn1.x86_64 #1 SMP Thu Jun 11 20:33:38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ## UPDATE ## As mentioned in the answers it was verified that /usr/bin was missing from my $PATH, so I've added it to my $PATH, and now when I get root by sudo su the commands are recognized, but if I get root by sudo -i they are still not recognizable, I still get the same error: [ec2-user@ip-172-31-33-121 ~]$ sudo -i -bash: id: command not found -bash: tty: command not found – [root@ip-172-31-33-121 ~]# yum -bash: yum: command not found ## UPDATE 2 ## We've identified that there is something overwriting my $PATH when i restart my shell when I reopen my shell my $PATH variable is overwritten to this: [root@ip-172-31-33-121 ec2-user]# echo $PATH /sbin:/bin:/usr/sbin:/usr/local/bin:/opt/aws/bin So I lose the /usr/bin again. We've thought changing the .bashrc would fix it, but it didn't this is my .bashrc now: # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi PATH=$PATH:/usr/bin; export PATH # User specific aliases and functions The result of env command: [root@ip-172-31-33-121 ec2-user]# env LESS_TERMCAP_mb= HOSTNAME=ip-172-31-33-121 LESS_TERMCAP_md= LESS_TERMCAP_me= SHELL=/bin/bash TERM=xterm HISTSIZE=1000 EC2_AMITOOL_HOME=/opt/aws/amitools/ec2 PYTHON_INSTALL_LAYOUT=amzn LESS_TERMCAP_ue= USER=root LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: SUDO_USER=ec2-user EC2_HOME=/opt/aws/apitools/ec2 SUDO_UID=500 USERNAME=root LESS_TERMCAP_us= PATH=/sbin:/bin:/usr/sbin:/usr/local/bin:/opt/aws/bin:/usr/bin MAIL=/var/spool/mail/ec2-user PWD=/home/ec2-user JAVA_HOME=/usr/lib/jvm/jre AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon LANG=en_US.UTF-8 SHLVL=1 SUDO_COMMAND=/bin/su HOME=/root AWS_PATH=/opt/aws AWS_AUTO_SCALING_HOME=/opt/aws/apitools/as LOGNAME=root CVS_RSH=ssh AWS_ELB_HOME=/opt/aws/apitools/elb LESSOPEN=||/usr/bin/lesspipe.sh %s AWS_RDS_HOME=/opt/aws/apitools/rds SUDO_GID=500 LESS_TERMCAP_se= _=/bin/env OLDPWD=/home/ec2-user ## UPDATE FINAL ## By adding PATH=$PATH:/usr/bin; export PATH to the file /etc/profile, we were able to fix sudo -i for good sudo su is still not working, but I guess I will just use **sudo -i** Thanks everybody!

I've read in a couple of places that the PATH is set in /etc/profile or the .profile file that's in the home dir. Are these the only places that the path is set in? I want a better understanding of it. In the /etc/profile file, as the following comment says "system-wide .profile file for the Bourne shell". Does that mean that profile files are the main configuration files for bash? In that file I don't see the PATH var being set at all. In the .profile file in the home directory there's this line: PATH="$HOME/bin:$PATH" That's resetting PATH by the looks because it's concatenating the already set $PATH string with $HOME/bin: right? But if etc/profile and ~/.profile are the only files setting PATH where is $PATH coming from in that line of code if it's not defined in /etc/profile? Can someone experienced please give a broad and detailed explanation of the PATH variable? Thanks!

Weird one, when I update flatpaks I get the following message in terminal:

Note that '/var/lib/flatpak/exports/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:

- /root/.local/share

However, if I run echo $XDG_DATA_DIRS I get the following:

/home/myname/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/

Sort of new to linux, so am I missing something? For context, I am using Fedora 37

In Ubuntu Desktop 24 ~~~ $ grep VERSION= /etc/os-release VERSION="24.04.2 LTS (Noble Numbat)" ~~~ When I open a Terminal window my $PATH has two copies of /snap/bin ~~~ $ echo $PATH | sed -e 's/:/:\n/g' /usr/local/sbin: /usr/local/bin: /usr/sbin: /usr/bin: /sbin: /bin: /usr/games: /usr/local/games: /snap/bin: /snap/bin ~~~ I found this is potentially added in both /etc/environment and in /etc/profile.d/apps-bin-path.sh ~~~ $ sudo grep -n snap.bin /etc/environment /etc/profile.d/apps*sh /etc/environment:1:PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" /etc/profile.d/apps-bin-path.sh:4:snap_bin_path="/snap/bin" /etc/profile.d/apps-bin-path.sh:5:if [ -n "${PATH##*${snap_bin_path}}" ] && [ -n "${PATH##*${snap_bin_path}:*}" ]; then /etc/profile.d/apps-bin-path.sh:6: export PATH="$PATH:${snap_bin_path}" ~~~ Perhaps it is added elsewhere too? If these are the only two files this is added, I guess the /etc/profile.d/apps-bin-path.sh is being executed before /etc/environment since the former checks it isn't already present. If I just want to reduce the number of references to /snap/bin in my PATH from two to one, which file is safest (or most appropriate) to prune?

I want to unpack Node.js (Linux Binaries (x64)) to a custom folder and use it for a few projects. The difficulties appear when I start using console. I can't use npm at all and I've got no idea how to install global modules in this case. For instance, I install gulp -g and even specify the installation path for it, but when I wish to use gulp, it doesn't work. So, again, I do not use package managers and /usr/lib folders, the whole node.js package in one, single folder. How to use it that way if possible at all? There may be a few more Node.js versions there and it would be greate to have a way of setting up the /paths/variables for the selected /folder/version of Node.js.

[username@MACHINE bin]$ sudo
sudo: Files/Microsoft: command not found

I can sudo just fine as root. I thought this might be due to spaces introduced into PATH by WSL, but for both the root and non-root accounts, neither enclosing all paths in quotes nor escaping the spaces fixes this problem. **EDIT:** This is apparently due to devtoolset-7 prepending my PATH with /opt/rh/devtoolset-7/root/usr/bin, which includes a sudo executable. I would rather not have to type /bin/sudo every time I wish to invoke superuser access; by what means may I make /opt/rh/devtoolset-7/root/usr/bin/sudo usable?

I’m attempting to add support for using Sublime Text and TextMate with files on the router: https://packagecontrol.io/packages/RemoteSubl . Essentially, the script needs to be added to the /usr/local/bin directory: curl -o /usr/local/bin/rmate https://raw.githubusercontent.com/aurora/rmate/master/rmate sudo chmod +x /usr/local/bin/rmate Unfortunately, the /usr/local/bin directory doesn’t exist (nor is it on the PATH): # echo $PATH /usr/bin:/usr/sbin:/bin:/sbin Is there a recommended location for user-related scripts, such that they are on the PATH?

I am trying to install SteamCMD on my Linux machine by using this guide . However, I ran into a problem after I created the user steam and installed SteamCMD. The whole error code is Command 'steamcmd' is available in '/usr/games/steamcmd' The command could not be located because '/usr/games' is not included in the PATH environment variable However, I am not that tech savvy with Linux. I am unsure how I am able to give the user steam access to that path, so it can execute the steamcmd application. Thanks in advance :)

How can I get Bash to list the first (or all) commands that match a given glob? For example, let's say I'm looking for a command called cat. I can do type cat and it will search $PATH and tell me there is a cat at /usr/bin/cat. But suppose I forgot its full name, but I remember that it starts with "ca". Then I can type ca and press tab and Bash will list all available commands starting with "ca". What if I forgot what it starts with, but I just remember that it contains "at" as a substring? If I type \*at\* and press tab it doesn't work. If I type type \*at\* it doesn't work either.

I want to add Pycharm to my path so that I may launch it from the command line from any directory in the same way that atom can launch from terminal if I type atom. I have already tried charm, pycharm-community, and believe instead I need to add this to my path? Also, how would I do this for other programs in general as well. Thanks for any help!

I can't change the PATH at gnome-shell level so I can execute programs in my ~/bin or ~/.local/bin folder from my .desktop files. I am able to easily define other variables through ~/.config/environment.d/envvars.conf e.g. TEXMFHOME. The problem is reported elsewhere and most recently on these pages: - https://www.reddit.com/r/archlinux/comments/i2ybvc/cant_change_path_in_environmentd5/ - https://gitlab.gnome.org/GNOME/gdm/-/issues/385 - https://gitlab.gnome.org/GNOME/gdm/-/commit/349e6af855a1c1dbee9af3e5881e00b66482d155 I have changed these files:

~/.bashrc : 
export PATH="$HOME/.local/bin:$PATH"

~/.config/environment.d/envvars.conf:
PATH=$HOME/.local/bin:$PATH
TEXMFHOME=$HOME/.texmf # this variable is available at gnome-shell level

~/.pam_environment
PATH        OVERRIDE=${HOME}/bin:${HOME}/.local/bin:${PATH}

/etc/environment
PATH=/home/farid/.local/bin:$PATH

And at my bash prompt in gnome-terminal, I get:

~$ /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator
GTK_MODULES=gail:atk-bridge:gail:atk-bridge
QT_ACCESSIBILITY=1
PATH=/home/farid/.local/bin:/home/farid/.local/bin:/home/farid/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PYTHONSTARTUP=/home/farid/.python_startup
GCC_COLORS="error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01"
VISUAL="vi EDITOR=vi SYSTEMD_EDITOR=vi"
TEXMFHOME=/home/farid/.texmf
TEXMFCNF=/home/farid/.texmf/web2c:/home/farid/.texmf/web2c:


~$ systemctl --user show-environment
HOME=/home/farid
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LOGNAME=farid
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
SHELL=/bin/bash
USER=farid
XDG_RUNTIME_DIR=/run/user/1000
GTK_MODULES=gail:atk-bridge
QT_ACCESSIBILITY=1
PYTHONSTARTUP=/home/farid/.python_startup
GCC_COLORS=$'error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
VISUAL=vi
TEXMFHOME=/home/farid/.texmf
TEXMFCNF=/home/farid/.texmf/web2c:
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=gnome
DISPLAY=:0
EDITOR=vi
GDMSESSION=gnome
GDM_LANG=en_US.UTF-8
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/64064a9f_0993_4156_8610_1df4e8733ddb
GNOME_TERMINAL_SERVICE=:1.92
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GPG_TTY=/dev/pts/0
GROFF_NO_SGR=1

The TEXMFHOME variable set in ~/.config/environment.d/envvars.conf file is available to Gnome-shell but PATH seems to be overridden by some program. I am not sure if it's related to systemd or Gnome-shell, But in the reddit link I shared above, a person says the problem stems from Gnome-shell. I expect that when I press alt+f2 and type an executable name which is present in ~/.local/bin/ to be executed. I reported the bug to Debian gnome-shell package maintainers as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104035 If I press alt+f2 and execute sh -c 'echo "$PATH" > /tmp/path', then the content of /tmp/path is:

cat /tmp/path
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

If I press alt+f2 and execute sh -c 'echo "$TEXMFHOME" > /tmp/TEXMFHOME', which is defined in ~/.config/environment.d/envvars.conf, then:

cat /tmp/TEXMFHOME
/home/farid/.texmf

I have recently installed PIPX on MAC running Big Sur and ZSH shell. During the install it prompted for the following to be added to the .zshrc file.... # Created by pipx on 2021-03-20 14:22:23 export PATH="$PATH:/Users/xxxx/.local/bin" eval "$(register-python-argcomplete pipx)" Running echo $PATH showed /Users/xxxx/.local/bin added to the end of my PATH variable. However, when I close the terminal and open up a new session, running echo $PATH now shows the location duplicated at the end of the PATH :/Users/xxxx/.local/bin:/Users/xxxx/.local/bin Opening and closing new terminal sessions doesn't seem to create any more additions to PATH it just remains at these 2 entries.... I have run typeset -U PATH path to remove the duplicate but each time I open up new terminal sessions it just duplicates again. Does anybody know how I can stop this from happening.....I would really like to keep my PATH variable as clean as possible.

I'm wondering where a new path has to be added to the PATH environment variable. I know this can be accomplished by editing .bashrc (for example), but it's not clear how to do this. This way: export PATH=~/opt/bin:$PATH or this? export PATH=$PATH:~/opt/bin

Bash has the built-in command "type", which indicates how each argument would be interpreted if used as a command name, for instance:

$ type myfunction
myfunction is a function
myfunction () 
{ 
    echo hello
}

$ type myfunctionalias
myfunctionalias is aliased to `myfunction'

$ type python
python is /usr/bin/python

In the last case, /usr/bin/python is a link, and its target is again a link:

$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Feb  5 09:05 /usr/bin/python -> python3

$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 7 Feb  5 09:05 /usr/bin/python -> python3.13

$ ls -l /usr/bin/python3.13
-rwxr-xr-x 1 root root 14352 Feb  5 09:05 /usr/bin/python3.13

It is possible to resolve a link with "readlink -f", however it is tedious to do it manually, since i requires up to three steps: type to resolve the alias source, type to resolve the alias target, and readlink to resolve any link. In practice, I am more often interested in what will actually be executed, rather than the single resolution steps. So I need a "type"-like tool that resolves the aliases and the links, ideally:

$ clevertype python
/usr/bin/python3.13

$ clevertype --verbose python
python is /usr/bin/python
/usr/bin/python links to /usr/bin/python3
/usr/bin/python3 links to /usr/bin/python3.13
Result: python resolves to /usr/bin/python3.13

And:

$ clevertype pythonalias
pythonalias resolves to /usr/bin/python3.13

$ clevertype --verbose pythonalias
pythonalias is aliased to `/usr/bin/python'
/usr/bin/python links to /usr/bin/python3
/usr/bin/python3 links to /usr/bin/python3.13
Result: pythonalias resolves to /usr/bin/python3.13

Does such a tool exist?

A fresh installed Ubuntu 24.04 system creates the first user account. That user account has by default the following $PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin. When I add a new linux user account via adduser or useradd, that new user only has the following $PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin. Directories /usr/games and /usr/local/games are missing. I even added the new user to the same groups as the default user, but that doesn't change anything. I really have no idea why the default user has the additional directories /usr/games and /usr/local/games in his $PATH but newly created user accounts have not. I want that newly created user accounts also have these directories within their $PATH. I also want to understand why the default user account has those but newly created user accounts have not. --- **PS** I greped ~ and /etc/ for games but I found nothing useful --- **PPS** I found out that when I directly login (SSH/console) as the newly created user, the newly created user has the missing directories in $PATH, it seems that those directories are only missing when using sudo -iu $NEWUSER, but why?

Im trying to make a .desktop file run a .sh which is stored in the same directory as the .desktop. The whole directory needs to be portable and moved from machine to machine. my run script is run.sh I've tried: [Desktop Entry] Type=Application Terminal=true Name=RunMe #Exec=sh -c "dirname %k/run.sh" #Exec=bash -c "export PATH=$PATH:dirname %k; bash run.sh;" #Exec=bash -c "export PATH=$PATH:dirname %k; sh run.sh;" Exec=bash -c "export PATH=$PATH:dirname %k; run.sh;" But nothing happens when I double click the .desktop file. If I double click 'run.sh' and choose 'run' the script runs fine. If I run the script from the command line with 'sh run.sh' it works fine. Any ideas, even just how I could debug which path its actually trying to run from?

I installed the latest version of Debian (netinstall).
I have the problem, that the terminal does not know commands like

,

, and so on.
When I do

shutdown

it tells me it is in

/usr/sbin

.

I fixed this on a different installation try by writing /usr/sbin into /etc/profile where the $PATH is written.
But this time it did not work.

I looked at this: https://wiki.debian.org/EnvironmentVariables , but either those files did not exist or I did not know where to put the path.
And doing export PATH=$PATH:usr/sbin is not permanent, it's gone after reboot, so that is garbage as well.

Edit: Wait, maybe I have to change the PATH in /etc/environment?!
I have to test this once I give Debian another try.

In POSIX compliant systems, is a path whose occurrences of (possibly overlapped) /./ have been substituted with / guaranteed to lead to the same target as the original one? Example:

#!/bin/bash

shopt -s extglob

some_command -- "${@//\/+(.\/)//}"

--- #### UPDATE: Given the comments, it is not equivalent, so I'll update the question: In POSIX compliant systems, is a path for which the occurrences of (possibly overlapped) /././ have been replaced with /./ guaranteed to lead to the same target as the original path?

New Linux user here, freshly transitioned from Windows 10 to Fedora 41. Lot's of experience with many OS's, including various *nix and Unix-like file systems. I have a standard practice of using symlinks from test folders to code repos in order to recreate the deployed production folder structure locally for testing, while keeping testing and the code repo cleanly separated. I have many projects set up like this for local testing. This looks as follows, for example:

`
~/dev
  test
    a-project
      app => ../../code/a-project/src
        (cfg)
        (web)
      dta
        cfg
  code
    a-project
      src
        cfg
        web

` Key to this problem is that the src/cfg folder (which in production is the app/cfg folder) holds files that have relative references to optional files in dta/cfg which are loaded if they exist in production, expected to be relative to the app/cfg folder. Thus ../../dta/cfg/Optional.json when deployed references the dta folder. The PWD is the application root (in testing, this is ~/dev/test/a-project and all paths in the software are specified relative to the PWD. These paths are manipulated in Java code, using Java's File class, so this is not a shell-behavior problem. This works perfectly well in Windows, since the filesystem takes the path app/cfg/../../dta/cfg/Optional.json to mean exactly what it looks like, and resolves the relative references first, resulting in dta/cfg/Optional.json (the leading app/cfg being eliminated by the following ../... But Linux apparently resolves the symlink *first* (app/cfg/ => dev/code/project/src/) and only then then applies the relative path segments ../../dta/cfg/Optional.json, resulting in a file not found because, of course, the file is *not* located in ~/dev/code/project/dta/cfg. Regardless of arguments about whether this is technically correct or not, is there any way that I can tell Linux at any level to resolve relative path segments before resolving symlinks so that this unexpected and unpredictable behavior does not occur? Apart from being confusing and counter-intuitive to me, I have a lot of existing code which expects paths to resolve relative references first, that is using the apparent path, not the underlying path. The file system for my dev work is ext4 with case folding enabled (having come from Windows, and needing to remain compatible with other devs using Mac and Windows), and I'd really, *really* like to avoid making a destabilizing, invasive change to a bunch of Java classes to implement the relative path resolution before passing the path to the OS; both because it's potentially brittle, leading to security flaws, and because it's only needed for my testing as production systems (Ubuntu Linux servers) do not need these symlinks.

I'm trying to compile wxWidgets using MingW, and I have cygwin in my path, which seems to conflict. So I would like to remove /d/Programme/cygwin/bin from the PATH variable and I wonder if there is some elegant way to do this. The naive approach would be to echo it to a file, remove it manually and source it, but I bet there is better approach to this.