Perl Returning error for ls -l command - perl

I am running a perl script from Nagios to check some files for certain characteristics on a windows machine. When I run the script from Nagios it responds with a result of:
UNKNOWN ERROR - execution of LANG=C ls -l resulted in an error 32512 -
My Code is from this GitHub with a single modification of line 168 so I can use it with windows:
use lib 'C$\Progra~1\Nagios\NRDS_Win\plugins';
The odd thing is the program actually outputs the expected result from the command line on the windows machine.
Here is the command:
check_files.pl -D c:\logs -F Health.log -a '~,300'
Here is an example:
CRITICAL - Health.log is 10703 (more than 300) seconds old - 1
Health.log files found
I modified line that defined LANG=C ls -l in the code but now i just get:
UNKNOWN ERROR - could not execute ls -l - No such file or directory

ls is unix command and by default there is no such command in windows.
If you need it, you can install it e.g. from GNU CoreUtils
You also need to change shell command on line 639 from LANG=C ls -l to just ls -l because in windows you can't set environment variables like that.

Related

Powershell - Run SCP command using CYGWIN but also expand variables

I need to expand variables before running the SCP command as a result I can't use single quote. If I run the script using double quotes in Powershell ISE it works fine.
But doesn't work if I run the script through command prompt.
I'm using zabbix to run the script which calls the script as [cmd /C "powershell -NoProfile -ExecutionPolicy Bypass -File .\myscript.ps1"]
Here is the code that needs to run SCP using Cygwin bash.
if ((test-path "$zipFile"))
{
C:\cygwin\bin\bash.exe -l "set -x; scp /cygdrive/e/logs/$foldername/dir1/$foldername.zip root#10.10.10.10:~/"
}
Output:
/usr/bin/bash: set -x; /cygdrive/e/logs/myfolder/dir1/server.zip root#10.10.10.10:~/: No such file or directory
If I run the same command above in Cygwin manually it works.
I even tried to use bash -l -c but then the SSH session is stuck maybe because the root#10.10.10.10 becomes $1 according to the documentation.
Documentation link
-c If the -c option is present, then commands are read from
the first non-option argument command_string. If there are
arguments after the command_string, the first argument is
assigned to $0 and any remaining arguments are assigned to
the positional parameters. The assignment to $0 sets the
name of the shell, which is used in warning and error
messages.
Figured it out. It was halting when using bash -c was due to StrictHostKeyChecking, the known hosts thing (where you get a prompt to type yes/no). I set the -v switch to SCP and it showed me the Debug logs where it was halting.
Had to set scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null options.
The complete line now looks like the following:
c:\$cygwin_folder\bin\bash.exe -c ("/usr/bin/scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -v -i /cygdrive/c/cygwin/home/myuser/.ssh/id_rsa /cygdrive/e/logs/$foldername/dir1/$foldername.zip root#10.10.10.10:~/")

How do I get pipe to work when passed in string for sh -c and su is involved

I have the below command
su - root -s /usr/bin/sh -c "java -version|grep build"
But the pipe to grep doesn't seem to work since it prints all lines regardless
java -version writes to standard error, not standard output.
su - root -s /usr/bin/sh -c "java -version 2>&1 |grep build"
2>&1 copies standard error to standard output, so that it gets fed through the pipe and into grep.
That said, grep doesn't have to be run as root, assuming the pipeline isn't being specified for use by something that just runs arbitrary code using su sh -c '...'.
su - root -s /usr/bin/sh -c 'java -version' 2>&1 | grep build

How to log the output along with error messages to a file while running a script on psql command line on Freebsd OS?

On RHEL, the below command works:
psql -h hostname -U username -p port_no -d database -f /tmp/myfile.sql &> logfile01.txt
On FreeBSD, this throws error:
"Invalid null command"
Please suggest.
If you use this only on the command line then there is no need to change the shell.
To redirect stdout and stderr to a file in C-Shell synthax simply use ">& filename".
Different story is, if you want to write shell scripts. Bourne Shell and it's clones (like i.e. Bash) are better suited for writing script. See this Unix FAQ "Csh Programming Considered Harmful": http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
This redirection works in bash
&> logfile01.txt
, but it does not work in csh which is the default shell in FreeBSD.
# set | grep shell
shell /bin/csh
# ls -la &> logfile01.txt
Invalid null command.
Bash is not installed by default. You can install it
pkg install bash
and configure it as the default shell.

Shell not picking correct path to run drush

I've got drush in /usr/local/bin. Running which drush returns /usr/local/bin/drush. However running drush displays "-bash: /usr/bin/drush: No such file or directory". Running /usr/local/bin/drush works correctly.
My $PATH is /usr/local/bin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
[added in an edit] Before I had this issue I removed a copy of the script that was at /usr/bin/drush. It wasn't built correctly.
What on earth could be causing this problem? I do not want to have to type out /usr/local/bin/drush every time; that's why /usr/local/bin is in my $PATH.
Have you run drush before in this shell, then moved it from /usr/bin to /usr/local/bin ? If so, the hash command will show that the shell has remembered the command in the /usr/bin location and will presume it's there without re-checking. Run hash -r will clear this list.
Worked example:
$ echo >/usr/bin/hello 'echo hello'
$ chmod +x /usr/bin/hello
$ hash
hits command
1 /bin/chmod
$ hello
hello
$ hash
hits command
1 /bin/chmod
1 /usr/bin/hello
$ which hello
/usr/bin/hello
$ mv /usr/bin/hello /usr/local/bin/
$ hello
bash: /usr/bin/hello: No such file or directory
$ hash
hits command
1 /usr/bin/which
1 /bin/chmod
1 /bin/mv
2 /usr/bin/hello
$ which hello
/usr/local/bin/hello
$ hash -r
$ hash
hash: hash table empty
$ hello
hello
$ hash
hits command
1 /usr/local/bin/hello

perl run two system commands error

So in my script I need to make to calls to unix, and I do it via the system command like so:
system "bash -i -c 'addmothernode'";
...
perl code ...
...
system "bash -i -c 'addnode -ip=$_'";
However, whenever I run both of these commands in the same script, for some reason my process is stopped like this:
[1]+ Stopped perl boot.pl
And the script can only be finished when I run fg %1. When I only have one of these system calls in, the perl script finishes successfully. But I need both commands because they depend on each other. Anyone have any ideas about what's going on? Thanks!
UPDATE:
A lot of answers below are saying I don't need to use bash -i to run a system command, and I know typically this is true but I need to use aliases that I have created and if I do not use this the aliases won't be recognized. So I do need bash -i.
This problem is unrelated to perl. You can easily reproduce the situation if you start two bashes in the interactive mode (-i) one after another:
$ cat 1.sh
bash -i -c 'sleep 1'
bash -i -c 'sleep 1'
$ bash 1.sh
[1]+ Stopped bash 1.sh
Of course it would be better to run bash in the non-interactive mode (without -i) or run the program directly, without bash, but if you need for some reason bash -i you can protect its run with setsid:
$ cat 1.sh
setsid bash -i -c 'sleep 1'
setsid bash -i -c 'sleep 1'
echo done
$ bash 1.sh
done
The bash -i means run an interactive shell; so you have two shells both reading from the terminal.
Try removing the -i options.
system "addmothernode";
should work.
To execute a command, bash is not needed. The Perl system function is like the system C function, it calls by default sh.
man system
exec
The standard to which the caller conforms determines which shell is used. See standards(5).
Standard Shell Used
______________________________________________________________
1989 ANSI C, 1990 ISO C, 1999 ISO C, /usr/xpg4/bin/sh
POSIX.1 (1990-2001), SUS, SUSv2, SUSv3,
XPG4
POSIX.1 (1988), SVID3, XPG3, no standard /usr/bin/sh
specified