I'm not great in the terminal, and I can't figure out why its returning this. It's probably really obvious so apologies for asking, but the executable file I'm referencing is definitely in that file path, and after researching I can't seem to find an answer:
/home/user/protoc-3.5.1-linux-x86_64/bin/protoc object_detection/protos /*.proto --python_out=.
object_detection/protos/*.proto: No such file or directory
(I can't cd into it as I need to do this in a particular directory)
Thanks
It seems bash is looking for a specific file that has the name "[star]" instead of using this as a wildcard.
I think you might need to use a pipe to get the desired result.
From your command line, it looks like protoc is the executable, located at /home/user/protoc-3.5.1-linux-x86_64/bin/protoc. And that you're giving it two arguments separated by a space: object_detection/protos and /*.proto. If you have spaces in the file path, you'll need to escape them or double-quote them:
protoc object_detection/protos\ /*.proto or
protoc "object_detection/protos /*.proto"
The odd thing is that the error message indicates differently:
object_detection/protos/*.proto: No such file or directory
Or possibly the protoc executable needs the absolute (complete) path for file arguments. If from your current working directory the command ls object_detection/protos/*.proto shows results for you, then you can try running your command like this to use absolute file paths:
/home/user/protoc-3.5.1-linux-x86_64/bin/protoc $PWD/object_detection/protos/*.proto
$PWD is an environment variable that contains your working directory path.
Related
At first I had
touch $NAME_OF_FILE$DATE.$FILE_EXT
then I changed it to
PATH="Logs/"
touch $PATH$NAME_OF_FILE$DATE.$FILE_EXT
The file is created correctly in the folder, however only echos are being printed in there because says commands are not found like grep, awk, and others.
EDIT: The folder is already created on my desktop
Thanks
Alan
PATH is an environment variable that specifies where executables are located and is used by your shell to look for commands executables (grep, awk, ...). You should not override it in your script.
Try:
MYPATH="Logs/"
touch $MYPATH$NAME_OF_FILE$DATE.$FILE_EXT
To understand what PATH is open a shell and type echo $PATH. You will see it contains the directories where your commands executables are.
I have a Tcl script that works on Windows. When I run it and pass in file names when prompted, usually with a relative directory path. On Windows the script will take absolute OR relative directory paths ... it works, no problems at all.
On Linux it will NOT work in the same way. It will only work if I spell out the full file path, e.g. /home/gxuser/input/test.txt ... It will NOT take relative directory paths like ./input/test.txt
By "work" I mean it should OPEN the file ... It is there and the permissions are fine.
On Linux the program fails with the following error:
couldn't open "./input/test.txt": no such file or directory
while executing
"open $upload r"
The offending line in the code is:
set infile [open $upload r]
What am I doing wrong? I presume, I have overlooked some nuance of the Tcl language, and assumed it should recognize relative paths.
Relevant information:
% puts $tcl_version
8.4
% info patchlevel
8.4.19
% uname -a
Linux gxengine 2.6.32-60-generic #122-Ubuntu SMP
It is possible that a function you call is changing the current working directory. There is no way to tell which one that could be without inspecting the code, but you can check if this is the case by displaying [pwd] before calling open.
Another way things could go wrong is by the script being started in different ways from Unix and Windows - e.g. by shortcut on Windows and from the command line off the PATH on Unix.
Where you have filenames passed in by the user and you can't be sure that code you call won't cd under your feet, you're advised to process the filenames into absolute filenames as soon as possible in your script, possibly even before any package require or source calls.
This is actually easy to do.
set absoluteFilename [file normalize $userProvidedFilename]
As long as this is done before the first cd (or chdir()/SetCurrentDirectory() at the C/C++ level) future changes of directory will not break the path. The script must be prepared to work with absolute filenames, but that's easily done.
You can turn a relative path into an absolute path with respect to any arbitrary directory with file join:
set filename [file join [file normalize $arbitraryLocation] $relativeFilename]
(The file join is smarter than just inserting a directory separator.)
I am using the 2003 textbook - http://www.amazon.com/Unix-Shell-Programming-3rd-Edition/dp/0672324903
My OS is linux L-ubuntu 13 which is not based on POSIX (I think)
It says that I can store who | wc -l in a file called nu and then execute nu. But, before that I need to make this file executable by using chmod +x file(s). This does not work. How do I make the nu "command" work ? I know I can do it by naming nu as nu.sh and then doing bash nu.sh, but I want to try this way also.
To execute a file that is not in the PATH, you must give a properly qualified directory name. While giving the name of the file in the current directory is sufficient as an argument to a program, in order to execute a shell script or other executable file, you must give at least a relative path. For example, if the file is in your home directory, which is also the working directory, any of the following are acceptable:
./nu
~/nu
/home/username/nu
However, simply nu will only attempt to search the PATH, which probably includes places such as /bin, /usr/bin, and so on.
So apparently, I can't source a script if that script is in the current directory. For example,
# source some/dir/script.sh
Ok
works fine, but if I'm in the same dir as the script, it errors out:
# cd some/dir
# source script.sh
-sh: source: script.sh: file not found
What gives? Is the only way around this to change directory?
I'm using bash v4.2.10 on Angstrom Linux if that's relevant.
Quoting the source man page:
source filename [arguments]
....
If filename does not contain a slash, file
names in PATH are used to find the directory containing file-
name.
So... source is trying to search your script.sh in the folders contained in PATH.
If you want to source a file in the current folder use
source ./script.sh
Use an absolute path -- source /root/path/to/some/dir/script.sh -- should sort you.
This can happen when the file is in the wrong format. I FTP'd a Korn Shell script from Windows. I could edit it, but got "not found [No such file or directory]" when I tried to run it. It turned out it was in DOS format, which was indicated in the file name line when I edited it in vi. After I re-FTP'd it, making sure it was being transferred as ASCII, it ran fine.
I have a program written in C, which is named computeWeight.c and to compile it i use the following code
chaitu#ubuntu:~$ gcc -Wall -o computeWeight computeWeight.c
//to execute it:
chaitu#ubuntu:~$ ./computeWeight
Do i have any mechansim where i can directly use as mentioned below,
chaitu#ubuntu:~$ computeWeight
Should i be changing any permissions on the executable to get this?
You need to add "." to your path. Some people regard this as dangerous, though. See for instance http://www.arsc.edu/support/policy/dotinpath.html .
The $PATH variable define the places where linux would look for executables (try typing echo $PATH in a terminal). You need to put that file in one of those places. One way is to add a bin folder in your home directory, put the executable file there, and add this line (which adds the bin directory in your home folder to the search path) to your .cshrc file so that it'd be executed for every shell:
set PATH = ($PATH $HOME/bin)
With that said I don't think typing ./ is that bad.
export PATH=$PATH:.