Script don't works

POSIX.1 said:
kerogaz You badly need to learn debugging. If you read "command not found" what does that tell you?
Click to expand...
I'm not interested in this blah blah. I'm interested in the system working properly.Well, maybe version 15 will work fine, let's wait.Why did MС start simply in all previous versions, but in version 14 MC -U ?
 
cracauer@ said:
I think OP is still struggling with invoking the script, not with anything inside the script.
Click to expand...
While thiis simple script work in bash in Arch linux and Debian but not work in sh FreeBSD?

#!/bin/sh
# cleanup
cd /var/log
cat /dev/null > messages

-- command not found
 
What happens when you do sudo /home/pal/MONITOR_IP? If that still fails, sudo this simple script and tell us what it outputs:
#!/bin/sh
pwd
/usr/bin/printenv | /usr/bin/grep PATH
/usr/bin/which tcpdump
 
bakul said:
What happens when you do sudo /home/pal/MONITOR_IP? If that still fails, sudo this simple script and tell us what it outputs:
#!/binsh
pwd
/usr/bin/printenv | /usr/bin/grep PATH
/usr/bin/which tcpdump
Click to expand...
This!
It happened to me recently, the PATH variable wasn't properly configured, it gave me the message "command cannot be found".
Pretty easy to verify, just invoke commands by using their full path, if it works it means the shell configuration file is not good or not sourced for some reason.
 
gotnull said:
This!
It happened to me recently, the PATH variable wasn't properly configured, it gave me the message "command cannot be found".
Pretty easy to verify, just invoke commands by using their full path, if it works it means the shell configuration file is not good or not sourced for some reason.
Click to expand...
.profile - Bourne Shell startup script for login shells
#
# see also sh(1), environ(7).
#

# These are normally set through /etc/login.conf. You may override them here
# if wanted.
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:$HOME/bin; export PATH

# Setting TERM is normally done through /etc/ttys. Do only override
# if you're sure that you'll never log in via telnet or xterm or a
# serial line.
# TERM=xterm; export TERM

EDITOR=vi; export EDITOR
 
bakul said:
What happens when you do sudo /home/pal/MONITOR_IP? If that still fails, sudo this simple script and tell us what it outputs:
#!/binsh
pwd
/usr/bin/printenv | /usr/bin/grep PATH
/usr/bin/which tcpdump
Click to expand...
sudo script.sh (#!/bin/sh)
Password:
sudo: script.sh: command not found
 
Ok. This is due to a setting in /usr/local/erc/sudoers:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
If you have another standard place where stash commonly used commands, you can add to above. But probably better to just stick to this and use full paths for non standard commands.
 
bakul said:
Ok. This is due to a setting in /usr/local/erc/sudoers:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
If you have another standard place where stash commonly used commands, you can add to above. But probably better to just stick to this and use full paths for non standard commands.
Click to expand...
But what can I do? My /usr/local/etc/sudoers :
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" What change?
 
I suggest *carefully* reading the manpage for sudo and how PATH gets used. I can't tell you what to do since I don't know what you are doing and why but between reading the relevant man pages and this thread you should be able to figure out what you need to do. It seems you are not very familiar so I suggest *not* editing the secure_path.
 
bakul said:
I suggest *carefully* reading the manpage for sudo and how PATH gets used. I can't tell you what to do since I don't know what you are doing and why but between reading the relevant man pages and this thread you should be able to figure out what you need to do. It seems you are not very familiar so I suggest *not* editing the secure_path.
Click to expand...
And the man page doesn't list all the gotchas. Give your users the ability to more(1) a file. Most people are surprised what this allows. Our junior sysadmins have been fooled by savvy clients requesting to be able to view files with more(1). Be knowledgeable. Understand and careful.
 
covacat said:
sudo sh -c script.sh and leave sudoers as is
Click to expand...
But why are there such difficulties with the 14.3 system I installed in January 2025? Everything works fine with the system I installed on another server in 2014 (version 10) and have consistently upgraded to 14.3 without these hacks; I can just start with ./script.sh
 
In the past I've run into differences between
sudo and "su -"
Not sure it it relates to the OP issue, but even if symlinked there may be a difference between /bin/sh and /bin/bash.

But maybe actually ask and look at information. shebang in a script means "when executing these things, run under the shebang shell". That doe not preclude things set in the user shell (my understanding/opinion) being available.

So my opinion, "sudo" may not be the same as "su -"
 
kerogaz said:
But why are there such difficulties with the 14.3 system I installed in January 2025? Everything works fine with the system I installed on another server in 2014 (version 10) and have consistently upgraded to 14.3 [...]
Click to expand...
There must be some difference between these two systems. You might be running different versions of security/sudo, are they the same?
pkg query -e '%n=sudo' '%n %v'
 
kerogaz said:
But why are there such difficulties with the 14.3 system I installed in January 2025? Everything works fine with the system I installed on another server in 2014 (version 10) and have consistently upgraded to 14.3 without these hacks; I can just start with ./script.sh
Click to expand...
Compare the config files between the two systems.

When I say "the config files", that is actually quite a few, for the path during login, su, sudo, profile, and such.
 
I think the sequential upgrade from version 10 to 14.3 sh works fine because it preserves the correct settings of version 10 (paths, etc.). But when installing version 14, the paths are all crooked, so you have to dance around the fire with a tambourine.
 
In the meantime, I'm running the script with tcpdump on a local network computer from ArchLinux. It work.
printenv
SHELL=/bin/bash
SESSION_MANAGER=local/pal:@/tmp/.ICE-unix/891,unix/pal:/tmp/.ICE-unix/891
WINDOWID=75497844
COLORTERM=truecolor
XDG_CONFIG_DIRS=/etc/xdg
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_MENU_PREFIX=xfce-
LC_ADDRESS=kl_GL.UTF-8
LC_NAME=kl_GL.UTF-8
SSH_AUTH_SOCK=/home/pal/.ssh/agent/s.XGNGPROv7u.agent.yCqngalK3A
XDG_CONFIG_HOME=/home/pal/.config
DESKTOP_SESSION=xfce
LC_MONETARY=kl_GL.UTF-8
SSH_AGENT_PID=960
EDITOR=nano
GTK_MODULES=canberra-gtk-module:canberra-gtk-module
XDG_SEAT=seat0
PWD=/home/pal
LOGNAME=pal
XDG_SESSION_DESKTOP=xfce
XDG_SESSION_TYPE=x11
PANEL_GDK_CORE_DEVICE_EVENTS=0
XAUTHORITY=/home/pal/.Xauthority
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/pal
MOTD_SHOWN=pam
HOME=/home/pal
LC_PAPER=kl_GL.UTF-8
LANG=en_US.UTF-8
XDG_CURRENT_DESKTOP=XFCE
VTE_VERSION=8201
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CACHE_HOME=/home/pal/.cache
XDG_SESSION_CLASS=user
TERM=xterm-256color
LC_IDENTIFICATION=kl_GL.UTF-8
USER=pal
DISPLAY=:0.0
SHLVL=1
LC_TELEPHONE=kl_GL.UTF-8
LC_MEASUREMENT=kl_GL.UTF-8
XDG_VTNR=7
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
LC_TIME=kl_GL.UTF-8
GTK3_MODULES=xapp-gtk3-module:xapp-gtk3-module
XDG_DATA_DIRS=/usr/local/share:/usr/share
BROWSER=firefox
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
GDMSESSION=xfce
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/pal
LC_NUMERIC=kl_GL.UTF-8
_=/usr/bin/printenv
 
You must log in or register to reply here.
Back
Top