Script don't works

kerogaz · 2025-11-26T07:29:29+0000

printenv SHELL
/bin/sh

SCRIPT :

Code:

#!/bin/sh


MONITOR_IP="10.44.1.1"

tcpdump -l -n -i  em1 any port 80 or port 443 |

grep "$MONITOR_IP" |
while read -r line
do
  if [[ "$line" == *"$MONITOR_IP"* ]]; then
    fi
done

Code:

sudo *MONITOR_IP
Password:
sudo: MONITOR_IP: command not found

(em1 - network card)

eternal_noob · 2025-11-26T07:37:15+0000

You need to make the script executable and the current working directory may not be in PATH.
Try

Bash:

chmod +x ip_monitor.sh
sudo ./ip_monitor.sh

SirDice · 2025-11-26T08:59:28+0000

Why grep the output for a specific IP when you can tell tcpdump(1) to only show the traffic from the IP address you're interested in?

Code:

tcpdump -l -n -i  em1 host "$MONITOR_IP" and \(port 80 or port 443\)

kerogaz · 2025-11-26T10:04:27+0000

eternal_noob said:
You need to make the script executable and the current working directory may not be in PATH.
Try

Bash:

chmod +x ip_monitor.sh sudo ./ip_monitor.sh

ls -l /home/pal/MONITOR_IP
-rwxrwxrwx 1 pal pal 670 Nov 26 09:37 /home/pal/MONITOR_IP

kerogaz · 2025-11-26T10:06:27+0000

The issue here isn't the script's contents or its permissions. It doesn't run as a script at all.

SirDice · 2025-11-26T10:08:59+0000

Keep in mind that sudo(8) is used to not only change to root, but this also changes the environment, including the path. sudo /home/pal/MONITOR_IP

kerogaz · 2025-11-26T10:12:26+0000

SirDice said:
Keep in mind that sudo(8) is used to not only change to root, but this also changes the environment, including the path. sudo /home/pal/MONITOR_IP

root@server:~ # printenv SHELL
/bin/sh

SirDice · 2025-11-26T10:13:51+0000

kerogaz said:
Code:

printenv SHELL /bin/sh

Your user's shell is irrelevant in case you didn't know. The shebang line of the script explicitly states which shell to use.

kerogaz · 2025-11-26T10:16:28+0000

HOME=/root
export HOME
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:~/bin
export PATH
TERM=${TERM:-xterm}
export TERM
PAGER=less
export PAGER

# set ENV to a file invoked each time sh is started for interactive use.
ENV=$HOME/.shrc; export ENV

# Query terminal size; useful for serial lines.
if [ -x /usr/bin/resizewin ] ; then /usr/bin/resizewin -z ; fi

# Uncomment to display a random cookie on each login.
# if [ -x /usr/bin/fortune ] ; then /usr/bin/fortune -s ; fi

SirDice said:
Your user's shell is irrelevant in case you didn't know. The shebang line of the script explicitly states which shell to use.

# .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
PAGER=less; export PAGER

kerogaz · 2025-11-26T10:20:49+0000

I uncommented the user's Path but it didn't help. ---command not found

SirDice · 2025-11-26T10:39:04+0000

/etc/profile and/or ~/.profile are only executed when sh(1) is started as a login shell. I get it's difficult to understand how the invocation works but the shell can be started in 4 different ways. And each way behaves a little differently regarding /etc/profile, ~/.profile and ~/.shrc (or wherever ENV is pointing to).

Code:

   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.

SirDice · 2025-11-26T10:58:38+0000

Oh,

kerogaz said:
Code:

sudo *MONITOR_IP sudo: MONITOR_IP: command not found

Why are you using a shell wildcard to execute it? Just use sudo ./MONITOR_IP

There are other issues with your script though, any port 80 or port 443 is an incorrect filter.

Code:

dice@molly:~/temp % sudo ./test.sh
tcpdump: can't parse filter expression: syntax error
dice@molly:~/temp % cat test.sh
#!/bin/sh


MONITOR_IP="10.44.1.1"

tcpdump -l -n -i  em0 any port 80 or port 443 |

grep "$MONITOR_IP" |
while read -r line
do
  if [[ "$line" == *"$MONITOR_IP"* ]]; then
    fi
done

Had to change the interface, don't have an em1.

cracauer@ · 2025-11-26T10:58:40+0000

sudo ./MONITOR_IP

and you can't have the blank line after the pipe symbol.

kerogaz · 2025-11-26T11:03:32+0000

Maybe change the user's environment to bash and run it from there?

kerogaz · 2025-11-26T11:08:25+0000

cracauer@ said:
sudo ./MONITOR_IP

and you can't have the blank line after the pipe symbol.

$ sudo ./MOITOR_IP
Password:
sudo: ./MOITOR_IP: command not found

SirDice · 2025-11-26T11:16:50+0000

kerogaz said:
Maybe change the user's environment to bash and run it from there?

Again, the user's (or root's) shell is irrelevant. The shebang in the script tells it which shell (or interpreter) to use.

cracauer@ · 2025-11-26T11:18:41+0000

kerogaz said:
$ sudo ./MOITOR_IP
Password:
sudo: ./MOITOR_IP: command not found

Dude...

kerogaz · 2025-11-26T12:24:50+0000

SirDice said:

/etc/profile and/or ~/.profile are only executed when sh(1) is started as a login shell. I get it's difficult to understand how the invocation works but the shell can be started in 4 different ways. And each way behaves a little differently regarding /etc/profile, ~/.profile and ~/.shrc (or wherever ENV is pointing to).

Code:

   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.

Thanks, but I don't need such details, I want to know how to run the script. It won't even run, not just any script #!/bin/sh

kerogaz · 2025-11-26T12:30:16+0000

This is happening on a system I installed in January of this year. On a system I installed in 2014 and have been consistently updating to 14.3 p5 since then, the scripts work and mс doesn't need to be launched as mс -u

kerogaz · 2025-11-26T12:51:11+0000

SirDice said:
Oh,

Why are you using a shell wildcard to execute it? Just use sudo ./MONITOR_IP

There are other issues with your script though, any port 80 or port 443 is an incorrect filter.

Code:

dice@molly:~/temp % sudo ./test.sh tcpdump: can't parse filter expression: syntax error dice@molly:~/temp % cat test.sh #!/bin/sh MONITOR_IP="10.44.1.1" tcpdump -l -n -i em0 any port 80 or port 443 | grep "$MONITOR_IP" | while read -r line do if [[ "$line" == *"$MONITOR_IP"* ]]; then fi done

Had to change the interface, don't have an em1.

I tried without em1 first, but the script didn't work, and I added em1 because in the command line "tcpdump -l -n -i em1 " work.

kerogaz · 2025-11-26T13:02:06+0000

I simplified the script to:

!#/bin/sh
tcpdump

---command not found

POSIX.1 · 2025-11-26T13:28:55+0000

kerogaz said:
!#/bin/sh

Typo in shebang.

kerogaz · 2025-11-26T13:48:07+0000

POSIX.1 said:
Typo in shebang.

#!/bin/sh
tcpdump
--command not found

SirDice · 2025-11-26T13:53:39+0000

Ehm, what does ls -l /bin/sh show?

You get a bit of an odd error if the shebang points to something that doesn't exist:

Code:

dice@molly:~/temp % cat test.sh
#!/does/not/exist

echo "Hello world"
dice@molly:~/temp % ./test.sh
./test.sh: Command not found.

It's not ./test.sh that cannot be found, it's the interpreter from the shebang that's not found.

POSIX.1 · 2025-11-26T13:55:41+0000

kerogaz You badly need to learn debugging. If you read "command not found" what does that tell you?

Script don't works

kerogaz

eternal_noob

SirDice

Administrator

kerogaz

kerogaz

SirDice

Administrator

kerogaz

SirDice

Administrator

kerogaz

kerogaz

SirDice

Administrator

SirDice

Administrator

cracauer@

kerogaz

kerogaz

SirDice

Administrator

cracauer@

kerogaz

kerogaz

kerogaz

kerogaz

POSIX.1

kerogaz

SirDice

Administrator

POSIX.1