I'm an owner of synology's diskstation NAS server running on special OS (mainly linux)
It has only access from internet. I established command line interface to access it using synology wiki. Now I try to install Counter-Strike server on it using SteamCMD. I just look in Valve Developer Community for it.
I'm writing the next:
mkdir csServer
cd csServer
wget http://media.steampowered.com/client/steamcmd_linux.tar.gz
tar xvfz steamcmd_linux.tar.gz
./steamcmd.sh
But the last line causes -sh: ./steamcmd.sh not found. However, I can see this file in the directory.
What actually can cause it?
//ADDED
The file is executable!
Your script contains a header which says #!/bin/bash, that is use /bin/bash to execute this script. Apparently, on your system /bin/bash is not present. I am not familiar with Synology environment, but you should be able to fix this problem by installing bash and then pointing your script to the right path, which should be /opt/bin/bash. The first line of your script should therefore look like the following
#!/opt/bin/bash
You could also use Synology default ash, but beware that you script might not work as it was written for bash.
Windows style end-of-lines (CRLF) can cause this issue. If your sh file contains Windows style end-of-lines, convert it to Linux style.
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I am attempting to install RetroPie as an app on Raspbian Stretch and I am done except for creating a desktop shortcut for it. The problem is that the only way to open RetroPie seems to be running a command in the command line. I can’t do it in terminal because it gives me an error saying that it can’t initialize the window. Is there a way to run a command line command as a shortcut or am I going to have to find another way of doing this?
P.S. Here is the tutorial that I followed to install RetroPie:
https://www.makeuseof.com/tag/install-retropie-app-raspberry-pi/
Probably your shell (on the raspberry) is GNU bash. So read the manual of GNU bash.
You probably want (once) to edit some Bash startup file (such as ~/.bashrc) to define functions and aliases there, and you could add executable shell scripts somewhere in your $PATH. I recommend having a $HOME/bin/ directory containing your scripts and executables, and have $HOME/bin/ early in your $PATH.
I can’t do it in terminal because it gives me an error saying that it can’t initialize the window.
Perhaps you need some display server (such as Xorg or Wayland) running (with a desktop environment or a window manager). You could run Xorg on your PC (on which you could install Linux) and connect to the raspberry using ssh -X then remote applications running on your Raspberry are displayed on your PC. IF your Raspberry is directly connected to a screen (via HDMI) you might run some Xorg server on it.
Is there a way to run a command line command as a shortcut
Yes, by making a shell alias or shell function or shell script. You need to understand how they work and change or create some appropriate file using some source code editor (I recommend GNU emacs, but the choice is yours and you might use any other editor such as vim, gedit, etc...): functions and aliases could be defined in your ~/.bashrc; shell scripts would usually have their own file with a shebang under your $HOME/bin/...
So I'm basically wanting to get a script to run on system boot. It's basically an SSH callback. I've tried a few ways that I've gotten to work in the past on other distributions, but having a little bit of difficulty here.
First thing I've tried was adding the /path/to/script.rb to /etc/rc.local. However, this file does not exist on the latest version of Kali Linux. I tried to create it and replicate my old Ubuntu rc.local file, but it didn't run on system startup.
Next thing I tried was creating an executable bash script in /etc/init.d/, following the update-rc.d script.sh defaults and making the file executable. Restarted and nothing. If I run the script manually, it works. I tried to redirect the output to a file in the tmp folder, but it doesn't appear that there are any errors from what I'm understanding.
Are there any other ways to get an auto run script started other than these two methods? Seem to be the most common way to get this working, but it's just not doing it for me.
Add script to
/etc/init.d
Run command:
chmod 755 /etc/init.d/script
Run command:
update-rc.d script enable
This question already has answers here:
Executable file generated using GCC under cygwin
(5 answers)
Closed 7 years ago.
Let me tell you my problem. I've a shell script which execute a Linux executable. I don't have access to the source code of this exe.
When I run the script on the Linux machine, there is no problem.
But, if I try to run the script on my Windows laptop, using cygwin, I have the error "cannot execute binary file".
There is any solution ?
Thanks !
From https://stackoverflow.com/a/4144536/5704102:
"... Cygwin is a compatibility layer, which aims to implement as much as possible of the POSIX and Linux APIs within Windows. This means that programs have to be compiled specifically for Cygwin ..."
What does this script look like? Is it a bash script? If so, you may want to try sh <scriptfile> in Cygwin. If this doesn't work, and it is a bash script, make sure you have sh.exe. Type sh and hit tab twice to check.
Another potential issue if it is a bash script is that you don't have something installed that Cygwin requires to run the script. Make sure all the commands the script is trying to run will work. If not, you may have to run the Cygwin installer and install whatever is needed to run the script.
Also, you may want to check permissions.
If the file has an exe extension, it SHOULD work on Windows unless it was compiled for 64 bit architecture and you're running a 32 bit OS. Otherwise, you could be missing some .dll files that the executable relies on.
Edit:
If this is the contents of your script:
echo START
/oper/file.exe
then it's likely you have the incorrect path. Cygwin paths typically start with /cygdrive/c/ in Windows. Go to where the file exists and type pwd to get the correct path, then modify your script accordingly.
Content of Script.sh in oper folder :
echo START
/cygdrive/c/Users/jo/oper/file.exe
In Cygwin terminal (in the right folder):
sh Script.sh
(Path updated)
I have a script file that I was given to run in windows using Cygwin. When I try to use this file I get the following error
-bash: /sigdet/filename: cannot execute binary file: Exec format error.
sigdet is the folder within the Cygwin directory that I have the script. Rawdata is the name of the directory with the raw data files that the script is supposed to analyze.
To try and solve this, I have changed the file permissions, I have checked to make sure that it is on a 64 bit machine and the script appears to have compiled on a 64-bit machine. After these steps, I don't know what else the problem could be. Here are the commands I've entered:
I first changed the directory like so:
$ cd /sigdet/
Then I ran the script that is suppsed to work:
$ /sigdet/filename -i rawdata
Does the script file need to have an extension in windows? I've tried changing it to a .sh extension with no luck. I'm told that it just works on other windows machines just how it is.
Thanks to anyone that can help with this.
Your file is not an executable. It most probably contains ELF executable which is designed for Linux operating system, or it's corrupt.
If your file was a shell script, or in fact anything that contained plain text, you'd get different errors (such as, "expected command name" or "unknown command: XYZ" etc.)
Scripts are not supposed to have file extensions, like any executables. On the other hand, they should have shebangs: small text located in the first line that tells the system the path to the interpreter. For example, a Python executable script might be named whatever and have #!/usr/bin/python3 or similar in the first line. When you run it through ./whatever in the shell, it'll look for python3 in /usr/bin and run your file like this: /usr/bin/python3 ./whatever. (In fact, thanks to this you can also specify additional parameters that get passed to the interpreter.)
There is also a chance that your script is valid, but it contains a shebang pointing to bad interpreter. If that is the case, then most likely the path is correct, otherwise you'd get /whatever/interpreter: bad interpreter: no such file or directory error or similar. But then, all the other points apply to the interpreter (which is just another executable...)
If the script and/or interpreter was meant to be executed on Windows or Cygwin at least, it should either contain aforementioned shebang (#!/path in the first name) or it should be Windows executable (in which case the file data should begin with MZ letters, you can inspect it in notepad.) If it isn't, it means the files you were given can't run on Cygwin.
Had this same problem. Added the following at the top of makefile:
export ARCH = CYGNUS
What happened during the make process is that Linux and Windows versions of the executables were created. You just have to use ./.exe versions.
In my case, I got the error when I used a wrong command to compile my C program. When I used the right command:
gcc myprog.c -o myprog.exe
the error was resolved.