I am running command pipenv run "python shotty/shotty.py" in my windows PowerShell. In return I am getting this error "The system cannot find the path specified". I do have folder shotty(in my current directory) and a file shotty.py within it.
Try python ./shotty/shotty.py
./ stands for the current directory
Remove the quotes.
pipenv run python shotty/shotty.py
With quotes, Powershell treats python shotty/shotty.py as one single argument, and tries to find a directory named python shotty, and a file named shotty.py in it. The arguments can be grouped correctly without quotes.
I had a similar problem and I wasn't using quotes in the command. I discovered it was because I had an apostrophe in my project's folder name. I renamed the folder without the apostrophe and recreated the pipenv for the new folder name and pipenv run works now.
Related
I try to use julia-1.6 with VScode, but I cannot find a path to the executable.
When I try to change the working directory via the julia prompt to the executable, I get an error message saying it's not a directory:
julia> cd("/Users/jjdegruijter/bin/julia")
Can anybody tell how to do it properly?
To get the path to your Julia executable, from the REPL, do:
joinpath(Sys.BINDIR, "julia")
You can start a REPL by just running julia from the terminal, or by pressing Alt-J Alt-O in VS Code (you can also instead type Ctrl-Shift-P, then choose Julia: Start REPL from that list).
Or, you can also directly run the above command from the terminal without starting a REPL: julia -e 'println(joinpath(Sys.BINDIR, "julia"))'.
If you just want to change working directory to the directory containing the executable (though I'm not sure why you'd want that here):
cd(Sys.BINDIR)
I am trying to use docker hub to automatically build something that builds fine locally. It fails saying:
Build process failed: stat /var/lib/docker/aufs/mnt/1be9db483fa6f3de2596b5261e7c450de8df503185e579278396f14ba179c257/bin/run.sh: not a directory
You can view the build itself here:
https://hub.docker.com/r/zbyte64/rethinkdb-tlsproxy/builds/bjclhq33kgwxxvn6nbfsgyh/
run.sh is in the same directory as Dockerfile, it seems the build path on dockerhub is different then where it stores the Dockerfile.
I have tried the following variations:
COPY run.sh /bin
ADD ./run.sh /bin
The COPY command (on Dockerhub's Docker version) expects the target file on the right hand side, not just the target directory. The following command should work for you even on Dockerhub.
COPY run.sh /bin/run.sh
Or if you want to use ADD, include the trailing slash.
ADD ./run.sh /bin/
What is actually happening? From https://docs.docker.com/engine/reference/builder/#add :
ADD src dest
"If dest does not end with a trailing slash, it will be considered a regular file and the contents of src will be written at dest."
Without the trailing slash on /bin, it expects run.sh to be a directory being copied to directory /bin.
I don't know why, but dockerhub wants the first argument of COPY or ADD to be a directory - not a file. I am running Docker 1.9.1 locally and that is not the case. I switched the Dockerfile to copy a resource directory instead of individual files and things started to work.
I want to work on a project, but I need to use docker for running the app, but the docker-compose up command fails with this error:
System error: exec: "./wait_to_start": stat ./wait_to_start:
no such file or directory
The wait_to_start command is an executable python script in the subfolder backend/.
I need to determine why it cannot be executed. Either it's been searched in the wrong path, or there are access right problems, or maybe the wrong python version is used.
Can I debug it with details, or login with SSH and check the files on the virtual machine? I'm too unexperienced with Docker...
You can either set the "workdir" metadata to make sure you are in the right place when you start a container or simply call /backend/wait_to_start instead of ./wait_to_start so you remove the need to be in the proper directory.
Do debug with docker-compose I would do this:
docker-compose run --entrypoint bash <servicename>
That should give you a prompt and let you inspect the file and working directory, so see what's wrong.
I am wondering if there is an identical command for copying a folder to current directory like it did using the old MS-DOS. Let's say my current directory location is:
/var/www/
I have folders and files at:
/home/hope/subfolder/docs/
/home/hope/subfolder/images/
/home/hope/subfolder/.config
/home/hope/subfolder/readme.txt
I know that the following command:
cp -rT /home/hope/subfolder .
will copy all the files (even dot hidden files) and folders within the "subfolder" folder to the current directory, so the result will be:
/var/www/docs/
/var/www/images/
/var/www/.config
/var/www/readme.txt
Looks like the command to that to copy the source folder to the current location is:
cp -rT /home/hope/subfolder ./subfolder
although this is fine, I find it that sometimes I will make mistakes for complicated folder names for the destination, so is there a way to use a command like:
cp -rT /home/hope/subfolder .
or even like this
cp -rT /home/hope/subfolder /var/www/.
to have the following result:
/var/www/subfolder/docs/
/var/www/subfolder/images/
/var/www/subfolder/.config
/var/www/subfolder/readme.txt
Thank you.
Just omit the -T parameter, as that's what prevents the command from working properly:
cp -r /home/hope/subfolder .
The -T parameter treats the target argument as a file, so no copying will be performed at all if that is actually a directory.
A friendly reminder: virtually all Unix commands have a --help command line argument that is worth trying out in case of a trouble :)
For me the main barrier was the /home part. I needed to copy files from a folder in my home that started with the letter 'a' to my current folder, which was not home. So I used:
cp home/tmp/a* ./
the first line worked for me. While I was trying commands like:
cp ~/home/tmp/a* ./
but this didn't work.
I was trying to set up a bash command in Terminal on a Mac.
The scripts run correctly when I execute them directly.
I set up symlinks in /usr/local/bin/ to the current location of the scripts. When I try to run it off the symlink, it doesn't work. I don't believe the issue is the $PATH, because pip, git, ipython all exist in this location. When I edit the $PATH setting, these fail.
Suggestions?
ls -l /usr/local/bin/foo and see where your symlink is actually pointing. Betcha it's broken.
If not, try running /usr/local/bin/foo. If that works, it was your PATH that's wrong, despite what you said in the OP.
The only other thing that would cause this behavior is if the script is reading $0 (its own name as executed). With a symlink, that will have a different value.
I found my own answer... The symlinks were created by an automated file which was gabbing my pwd. I was also using virtualenv, so to get it to work, I had to activate the virtualenv and be inside the folder that had the script that created the symlinks.
I install my commands in $HOME/bin instead of /usr/local/bin, but it does not matter much. As hinted in the comments, one question is whether the symlinks are set correctly.
Check which command the shell thinks you should execute: which command
Check that the link in /usr/local/bin points to the correct file (and has execute permission, etc):
ls -l /usr/local/bin/command
ls -lL /usr/local/bin/command
Check that the interpreter path in the shebang is correct:
file /usr/local/bin/command
Check that /usr/local/bin is actually on your PATH: echo $PATH
If none of that shows up a problem, show us the results of the commands above.