I'm new to Google Cloud Storage, but have managed to find every answer to my questions online, but now I'm trying to upload files using the Google Cloud SDK and it works great for files with no spaces "this_file_001.txt" but if I try to upload a file with spaces "this file 001.txt" the system won't recognize the command. The command I'm using that works is
gsutil -m cp -r this_file_001.txt gs://this_file_001.txt
Now the same command with spaces doesn't work
gsutil -m cp -r this file 001.txt gs://this file 001.txt
Is there any way to accomplish this task?
Thanks in advance.
Putting the argument into quotes should help. I just tried the commands below using Google Cloud Shell terminal and it worked fine:
$ gsutil mb gs://my-test-bucket-55
Creating gs://my-test-bucket-55/...
$ echo "hello world" > "test file.txt"
$ gsutil cp "test file.txt" "gs://my-test-bucket-55/test file.txt"
Copying file://test file.txt [Content-Type=text/plain]...
Uploading gs://my-test-bucket-55/test file.txt: 12 B/12 B
$ gsutil cat "gs://my-test-bucket-55/test file.txt"
hello world
That said, I'd avoid file names with spaces if I could.
Alexey's suggestion about quoting is good. If you're on Linux or a Mac, you can likely also escape with a backslash (). On Windows, you should be able to use a caret (^).
Linux example:
$> gsutil cp test\ file.txt gs://bucket
Windows example:
c:\> gsutil cp test^ file.txt gs://bucket
Quotes work for both platforms, I think.
Related
Dipping my toes into Bash coding for the first time (not the most experienced person with Linux either) and I'm trying to read the version from the version.php inside a container at:
/config/www/nextcloud/version.php
To do so, I run:
docker exec -it 1c8c05daba19 grep -eo "(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?" /config/www/nextcloud/version.php
This uses a semantic versioning RegEx pattern (I know, a bit overkill, but it works for now) to read and extract the version from the line:
$OC_VersionString = '20.0.1';
However, when I run the command it tells me No such file or directory, (I've confirmed it does exist at that path inside the container) and then proceeds to spit out the entire contents of the file it just said doesn't exist?
grep: (0|[1-9]\d*).(0|[1-9]\d*).(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-])(?:.(?:0|[1-9]\d|\d*[a-zA-Z-][0-9a-zA-Z-]))))?(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?: No such file or directory
/config/www/nextcloud/version.php:$OC_Version = array(20,0,1,1);
/config/www/nextcloud/version.php:$OC_VersionString = '20.0.1';
/config/www/nextcloud/version.php:$OC_Edition = '';
/config/www/nextcloud/version.php:$OC_VersionCanBeUpgradedFrom = array (
/config/www/nextcloud/version.php: 'nextcloud' =>
/config/www/nextcloud/version.php: 'owncloud' =>
/config/www/nextcloud/version.php:$vendor = 'nextcloud';
Anyone able to spot the problem?
Update 1:
For the sake of clarity, I'm trying to run this from a bash script. I just want to fetch the version number from that file, to use it in other areas of the script.
Update 2:
Responding to the comments, I tried to login to the container first, and then run the grep, and still get the same result. Then I cat that file and it shows it's contents no problem.
Many containers don't have the GNU versions of Unix tools and their various extensions. It's popular to base containers on Alpine Linux, which in turn uses a very lightweight single-binary tool called BusyBox to provide the base tools. Those tend to have the set of options required in the POSIX specs, and no more.
POSIX grep(1) in particular doesn't have an -o option. So the command you're running is
grep \
-eo \ # specify "o" as the regexp to match
"(regexps are write-only)" \ # a filename
/config/www/nextcloud/version.php # a second filename
Notice that the grep output in the interactive shell only contains lines with the letter "o", but not for example the line just containing array.
POSIX grep doesn't have an equivalent for GNU grep's -o option
Print only the matched (non-empty) parts of matching lines, with each such part on a separate output line. Output lines use the same delimiters as input....
but it's easy to do that with sed(1) instead. Ask it to match some stuff, the regexp in question, and some stuff, and replace it with the matched group.
sed -e 's/.*\(any regexp here\).*/\1/' input-file
(POSIX sed only accepts basic regular expressions, so you'll have to escape more of the parentheses.)
Well, for any potential future readers, I had no luck getting grep to do it, I'm sure it was my fault somehow and not grep's, but thanks to the help in this post I was able to use awk instead of grep, like so:
docker exec -it 1c8c05daba19 awk '/^\$OC_VersionString/ && match($0,/\047[0-9]+\.[0-9]+\.[0-9]+\047/){print substr($0,RSTART+1,RLENGTH-2)}' /config/www/nextcloud/version.php
That ended up doing exactly what I needed:
It logs into a docker container.
Scans and returns just the version number from the line I am looking for at: /config/www/nextcloud/version.php inside the container.
Exits stage left from the container with just the info I needed.
I can get right back to eating my Hot Cheetos.
I'm trying to use snakemake with a docker image, but am having trouble with the docker volume. Unfortunately, there are no details on how to use 'singularity-args' to do this.
My snakemake file is:
rule all:
input:
'a/file3.txt'
rule step1:
output:
touch('a/file1.txt')
rule step2:
input:
rules.step1.output[0]
output:
'a/file2.txt'
params:
text = 'this is a test',
path = '/data/file2.txt'
singularity:
"docker://XXX/test"
shell:
"python test.py {params.text} {params.path}"
rule step3:
input:
rules.step2.output[0]
output:
touch('a/file3.txt')
The docker image is basically a python file that writes a string to file (for testing purposes). I'm trying to mount my home directory to the docker /data directory. With docker, I'm able to mount a volume using '-v'.
What is the correct way of doing this with snakemake?
I've tried the following commands (on MacOS and Ubuntu 18.04) and both have failed.
snakemake -s pipeline.py --use-singularity --singularity-args “-B /home/XXX/snakemake/a:/data”
snakemake -s pipeline.py --use-singularity --singularity-args “-B /home/XXX/snakemake/a”
The error message is:
No rule to produce /home/XXX/snakemake/a:/data” (if you use input functions make sure that they don't raise unexpected exceptions).
Am I missing a step?
Thanks in advance!
Just a trivial check... In your command lines you have tilted double quotes (“) instead of the straight ones ("), e.g.:
snakemake -s pipeline.py --use-singularity --singularity-args “-B /home/XXX/snakemake/a”
Maybe you are are copying and pasting from a text editor that uses the tilted quotes? I would use straight quotes as the other type would probably be interpreted in the wrong way.
I was able to get it working on Ubuntu 18.04 with the following command:
SINGULARITY_BINDPATH=“/home/XXX/snakemake/a:/data”; snakemake -s pipeline.py --latency-wait 10 --use-singularity
Unfortunately I wasn’t able to get the flag “--singularity-args” to work. Regardless of using ‘--bind’ or ‘-B’, I got the error “No rule to produce /Users/XXX/Devel/snakemake/a:/data”.
I’m using Snakemake 5.6.0 inside a Python3 virtual environment.
Also, on a side note, I don’t believe the MacOS singularity binary works. It had issues with Snakemake.
This work-around is good enough for now.
UPDATE
While this solution worked, the real solution (typo) was provided by #dariober.
After the latest updates to gcloud and docker I'm unable to access images on my google container repository. Locally when I run: gcloud auth configure-docker as per the instructions after updating gcloud, I get the following message:
WARNING: `docker-credential-gcloud` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
gcloud credential helpers already registered correctly.
Running which docker-credential-gcloud returns docker-credential-gcloud not found.
I have no other gcloud-related path issues and for the life of me can't figure out how to install/add docker-credential-gcloud to path. Here's what I have installed (shown via gcloud version):
Google Cloud SDK 197.0.0
beta 2017.09.15
bq 2.0.31
container-builder-local
core 2018.04.06
docker-credential-gcr
gsutil 4.30
I also have Docker CE Version 18.03.0-ce-mac60 (23751).
Here's my $PATH:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
I also ran source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc on original gcloud install.
Notice: All docker-credential-gcr below can be replaced with docker-credential-gcloud. I think it is just different versions of gcloud, I might be wrong.
I used Homebrew Cask to install gcloud too. I installed docker-credential-gcr with
$ gcloud components install docker-credential-gcr
And then like you said, which docker-credential-gcr doesn't gave you anything.
So I ran which gcloud to find there is a symlink to gcloud in /usr/local/bin. This symlink is created by Homebrew when you installed gcloud at first place. Now docker-credential-gcr wasn't installed by Homebrew but by gcloud itself, so there isn't a symlink.
I called readlink /usr/local/bin/gcloud and found out gcloud is installed in /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/.
Then:
$ ls /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin
There you should see docker-credential-gcr listed there.
I simply linked it to /usr/local/bin:
$ ln -s \
/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/docker-credential-gcr \
/usr/local/bin/
Then run:
$ docker-credential-gcr configure-docker
It should succeed.
Just had the same issue on Windows, running Docker with Linux containers, Docker engine v19.03.8. Using docker compose. I do not use gcloud for my dockerfiles...
DT1001 dockerpycreds.errors.InitializationError:
docker-credential-gcloud not installed or not available in PATH
Option 1: Edit the docker configuration file and remove all gcloud entries from there.
Windows c:/Users/<your account>/.docker/config.json
Linux & MacOS ~/.docker/config.json
Option 2: Go to Troubleshoot -> Reset to factory defaults.
After this my docker compose was creating containers and running the images without any issues.
On MacOS
Step 1：
Install gcloud and docker-credential-gcr,
following this tutorial
Step 2:
$ ln -s /usr/local/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
Step 3:
$ rm -rf ~/.docker
Step 4:
$ docker-compose build --pull
Finished!
Never found a way to directly resolve the docker-credential-gcloud issue, but the following got me up and running again. WARNING: the following will delete all your existing docker images and install a bunch of gcloud utilities:
gcloud components install docker-credential-gcr,
Restart the terminal completely
docker-credential-gcr configure-docker.
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
umount /var/lib/docker/overlay2
rm -rf /var/lib/docker
Restart the terminal completely.
The new version of google-cloud-sdk has only docker-credential-gcr but not docker-credential-gcloud anymore. On the other hand one of my python packages always requested docker-credential-gcloud.
The solution was to symlink docker-credential-gcloud to docker-credential-gcr:
ln -s /path/to/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
ls -l /usr/local/bin | grep docker should now print:
...
docker-credential-gcloud -> /path/to/google-cloud-sdk/bin/docker-credential-gcr
...
Usually, this error indicates that your $PATH variable has been clobbered by a package or program you have recently installed so that the Google Cloud SDK can't be found.
$PATH is altered by many programs when they install by altering ~/.profile, ~/.bash_profile or ~/.bashrc or their non-bash equivalents. With a bad $PATH, Google Cloud SDK is configured in docker but can't be seen as executables so we get this error. This assumes you have used the Google Cloud SDK in the past, but if gcloud is configured with your docker then you probably have. Don't reinstall gcloud or disable it, you already have it on your system and that is fine.
The solution then is to fix your $PATH, not to install anything.
echo $PATH
This should be a pretty long : delimited list of directories that your files are in. Do you see a google-cloud-sdk/bin in the string? Is the string way too short given all the trouble you've gotten into in your life on this computer? You use NVM but it is missing? Use Homebrew but it is missing? Try brew from the command line, does it work?
If the answer is "no" to any of the above, inspect the files above to see if there are any new entries at the bottom of each that might have broken things. Did you just install anything new?
Something is clobbering your $PATH and you need to figure out what that is. For me it is usually something to do with Anaconda Python via the conda init command. For you it might be nvm or something else. Figure out what it is and fix the problem. Don't start over with a new $PATH and install the same stuff over again or disable gcloud authentication.
It really seems to be something with the Homebrew Cask. I uninstalled the cask and then reinstalled the Google Cloud SDK by manually downloading the tar ball and running the packaged install script as described there.
Now docker-credential-gcloud is in my path:
$ which docker-credential-gcloud
/Users/moritz/google-cloud-sdk/bin/docker-credential-gcloud
I can't figure out what Google is trying to achieve here. On Linux there is docker-credential-gcloud and on Windows there is docker-credential-gcr.exe, and then there is docker-credential-gcloud.cmd which calls gcloud auth docker-helper. This is kind of a nightmare if you're trying to write portable build scripts or gradle rules because not everything seems capable of finding and calling docker-credential-gcloud.cmd when you exec docker-credential-gcloud... it might work from the dos prompt, but in general doesn't work.
After a ton of fooling around with .bat scripts, cygwin scripts, .cmd scripts and so forth, I found the best solution was to go into the gcloud installation and just copy docker-credential-gcr.exe docker-credential-gcloud.exe ... not a very satisfying solution, but is the only thing I found that would do the trick.
I got the issue when I tried to SSH from Google Cloud Build into an Engine VM Instance, so I had
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['compute', 'ssh',
'--project', '$PROJECT_ID',
'--zone', 'asia-southeast1-b',
'--strict-host-key-checking=no',
'username#instance-1',
'--command' ,'sh start.sh'
My start.sh
#!/bin/sh
echo "Started: $(date --iso-8601=seconds)"
docker pull gcr.io/aaa/bbbc/cccc
echo "Finished: $(date --iso-8601=seconds)"
The issue was How to set PATH when running a ssh command?
https://unix.stackexchange.com/questions/332532/how-to-set-path-when-running-a-ssh-command
So I just faced the same problem where I am trying to pull an image from GCR to an GCP instance and want to share my solution.
I ran gcloud auth configure-docker and got the warning:
WARNING: `docker-credential-gcloud\` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
I applied the accepted answer for this thread and ran gcloud components install docker-credential-gcr and got a long error:
ERROR: (gcloud.components.install) You cannot perform this action because this Cloud SDK installation is managed by an external package manager.
Please consider using a separate installation of the Cloud SDK created through the default mechanism described at: https://cloud.google.com/sdk/
When no solution was working, I uninstalled the Google provided google-cloud-sdk package that was installed via snap and instlled with distro specifice package manager, for me that is apt-get as instructed in the Installing Google Cloud SDK: Installation options page and re-ran the gcloud auth configure-docker and this time it solved my problem.
In my case the problem was due to how WSL 1 works with Docker on Windows. At first I only installed and initialized gcloud in WSL Ubuntu, not in Windows. However as Docker daemon is actually run by Windows, you need to install gcloud for Windows as well (and don't forget to run all of the inits and authorizations there).
On Windows 10/11, you need to ensure that C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ is added to your system $PATH environment variable. It may not have been added if the Google Cloud SDK was not able to add it during GCloud installation. So add it manually like this:
Windows Task Bar ➔ Press the search icon 🔍 or the search bar
Type "environment" ➔ and click on "Edit the System Environment Variables" (ensure that you have Administrator access)
At the bottom of the dialog, click the Environment Variables... button
System Variables ➔ click Path ➔ Edit... ➔ New ➔ paste in C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ (replace "USERNAME" with your username)
Close and restart any open Command Prompt windows.
Then verify on the Git Bash for Windows console:
Optional: Note that the AppData folder is hidden by default, so you may want to unhide AppData first, to see its contents.
Restart the Git Bash Terminal window
echo $PATH ➔ This should print a long string that contains: :/c/Users/USERNAME/AppData/Local/Google/Cloud SDK/google-cloud-sdk/bin
where docker-credential-gcloud ➔ This should print C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\docker-credential-gcloud.cmd
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env
I'm writing a script, and I need to look up a command on the user's $PATH and get the full path to the command. The problem is that I don't know what the user's login shell is, or what strange stuff might be in their do files. I'm using the bourne shell for my simple little script because it needs to run on some older Solaris platforms that might not have bash.
Some implementations of "which" and "whence" will source the user's dot files, and that isn't really portable to all users. I'd love a simple UNIX utility that would just do the basic job of scanning PATH for an executable and reporting the full path of the first match.
But I'll settle for any /bin/sh solution that is stable for all users.
I'm looking for a solution that is better than writing my own /bin/sh loop that chops up $PATH and searches it one line at a time. It would seem that this is common enough that there should be an reusable way to do it.
My first approximation of the "long way" is this:
IFS=:
for i in $PATH; do
if [ -x $i/$cmd ]; then
echo $i/$cmd
fi
done
Is there something simpler and portable?
The answer seems to be the 'type' built-in.
% /bin/sh
$ type ls
ls is /bin/ls
Maybe the whereis command will work for you?
whereis -b -B `echo $PATH | sed 's/:/ /g'` -f [commands]
e.g. on my computer, this works:
whereis -b -B `echo $PATH | sed 's/:/ /g'` -f find man fsc
And results in:
find: /usr/bin/find
man: /usr/bin/man
fsc: /opt/FSharp-2.0.0.0/bin/fsc.exe /opt/FSharp-2.0.0.0/bin/fsc
One caveat from the whereis man page:
Since whereis uses chdir(2V) to run faster, pathnames given
with the -M, -S, or -B must be full; that is, they must begin
with a `/'.
This question is answered in details here: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then. Bottom line: use command -v ls.