I am writing a spreadsheet that has paths to files.
It will be used in a custom script with some not-well-known software that the company I work at uses. The custom script will read the column in the spreadsheet that has the path + file, in order to find a file residing at that location.
The spreadsheet has path+file entries such as
C:3.jpg
but, usually, in real life, I see a path+file written like this:
C:\3.jpg
Does it matter which way it is written?
Yes. The first means 3.jpg in whatever the current directory is on drive C, while the second means 3.jpg in the root directory of drive C.
In other words, if you're at a command prompt:
C:\Temp>
then C:3.jpg would refer to C:\Temp\3.jpg, while at the prompt
C:\Users\silph>
referring to C:3.jpg would be C:\Users\silph\3.jpg.
On the other hand, at the same two prompts (C:\Temp> and C:\Users\silph>), referring to C:\3.jpg would always refer to the same 3.jpg located in the root of drive C:.
Related
I want to write the following bash script which copies files from one GCS bucket to another with renaming options.
My input folder is gs://test-rtt-integration/result/frd/*.orc
and my destination folder is gs://test-rtt-integration/recent_files/frd
The renaming of the copied file should be done based on the name provided from gs://test-rtt-integration/complex-files/TAN/recent_files/today/frd
once the copy with renaming is done I need to clean gs://test-rtt-integration/result/frd
I tested the following commands, but they are not working properly
NAME = "$(gsutil ls gs://test-rtt-integration/complex-files/TAN/recent_files/today/frd)"
gsutil mv gs://test-rtt-integration/result/frd/*.orc gs://test-rtt-integration/recent_files/frd/$NAME
gsutil rm -rf gs://test-rtt-integration/result/frd
( all .orc files and other files should be deleted)
But this is not working properly as I have to split the NAME based on / and get the last split , so if the result of split is called SPLIT , I have to do gsutil mv gs://test-rtt-integration/result/frd/*.orc gs://test-rtt-integration/recent_files/frd/$SPLIT
Any idea on how to do this?
The question is a little bit confusing. You say that you want to move files from one Google Cloud Storage bucket to another, but all the operations are made in one single bucket called test-rtt-integration.
However, as soon as you get the file location with the command gsutil ls gs://[BUCKET_NAME]/folder e.g. gs://[BUCKET_NAME]/folder/[FILENAME].orc, since the gs://[BUCKET_NAME]/folder/ part is always the same for all the objects in the folder, just replace it with null and you will get only the object name at the end as [FILENAME].orc etc.
I am not sure if this is exactly what you are looking for, but I did a little bit of coding myself and I have created a bash script that:
Gets the name of each object from gs://[BUCKET_NAME]/from bucket folder
Copy all objects from gs://[BUCKET_NAME]/from bucket folder to the gs://[BUCKET_NAME]/to/ bucket folder
Delete all objects from gs://[BUCKET_NAME]/from bucket folder
Inside there are comments that explain how every operation works in details. If that is not exactly what you are looking for, you can get the basic idea of how that works and implement it in different way that will suit you better. I have tested the scrip myself in Google Cloud Shell and it is working. The example code can be found in GitHub.
My website runs on a third party server, and I encountered directories with the following permissions:
folder1 drwsr-s---
folder2 drwxr-s---
folder3 drwxr-x---
I'm familiar with the d, the r, the w, the x (for folders), and the -. While editing (in Filezilla), it seems all of these are equal to chmod 750.
man chmod tells me that s stands for "set user or group ID on execution". What does that mean? And how come it maps onto the same chmod code? Should I worry about this on the server?
The 's' bits are referred to as the "setuid" and "setgid" bits. What it does depends on the file type.
On a directory, as in your example, these bits set the default user or group for all files created in the directory.
EG, if you have a directory owned by foo:foo, with the setuid and setgid bits set, then all files created in that directory will be owned by foo:foo, regardless of who creates them.
In your example, the "setgid" bit is set for each directory. This means that for every file created in these directories, the owner will be the user who created the file, but the group will be set to match the directory's group, rather than the user's main group.
How do . and .., as paths (vs. ranges, e.g., {1..10}, which I'm not concerned with), really work? I know what they do, and use them all the time, but don't fully grasp how/where they're interpreted. Does the shell handle them? The interpreting process? The OS?
The reason why I'm asking is that I'd like to be able to use ... to refer to ../.., .... to refer to ../../.., etc. (up to some small finite number; I don't need bash to process an arbitrarily large number of dots). I.e., if my current directory is /tmp/let/me/out, and I call cd ..., my resulting current directory should be /tmp/let. I don't particularly care if ... etc. show up in ls -a output like . and .. do, but I would like to be able to call cat /tmp/let/me/out/..../phew.txt to print the contents of /tmp/phew.txt.
Pointers to relevant documentation appreciated as well as direct answers. This kind of syntax question is very hard to Google.
I'm using bash 4.3.42, by the way, with the autocd and globstar shell options.
. and .. are genuine directory names. They are not "sort-cuts", aliases, or anything fake.
They happen to point to the same inode as the other name you use. A file or directory can have several names pointing to the same inode, these are usually known as hard links, to distinguish them from symbolic (or soft) links.
If you are on Linux or OS X you can use stat to look at most of the inode metadata - it is what ls looks at. You will see there is an inode number. If you stat . and stat current-directory-name you will see that number is the same.
The one thing that is not held in the inode is the filename - that is held in the directory.
So . and .. reside in the directory on the file system, they are not a figment of the shell's imagination. So, for example, I can use . and .. quite happily from C.
I doubt you can change them - personally I have never tried and I never will. You would have to change what these filenames linked to by editing the directory. If you managed it you would probably do irreparable damage to your file system.
I write this to clarify what has already been written before.
In many file systems a DIRECTORY is a file; a special type of file that the file system identifies as being distinctly a directly.
A directory file contains a list of names that map to files on the disk
A file, including a directly does not have an intrinsic name associated with it (not true in all file systems). The name of a file exists only in a directory.
The same file can have an entry in multiple directories (hard link). The same file can then have multiple names and multiple paths.
The file system maintains in every directory entries for "." and ".."
In such file systems there are always directory ENTRIES for the NAMES "." and "..". These entries are maintained by the file system.
The name "." links to its own directory.
The name ".." links to the parent directory EXCEPT for the top level directory where it links to itself (. and .. thus link to the same directory file).
So when you use "." and ".." as in /dir1/dir2/../dir3/./dir4/whatever,
"." and ".." are processed in the exact same way as "dir1" and "dir2".
This translation is done by the file system; not the shell.
cd ...
Does not work because there is no entry for "..." (at least not normally).
You can create a directory called "..." if you want.
You can actually achieve something like this, though this is an ugly hack:
You can run a command before every command entered to bash, and after every command. For that you trap the DEBUG pseudo signal and set a command to PROMPT_COMMAND, respectively.
trap 'ln -s ../.. ... &>/dev/null | true' DEBUG
PROMPT_COMMAND='rm ...'
With this, it seems like there's an additional entry in the current directory:
pwd
# /tmp/crazy-stuff
ls -a
# . .. ... foo
ls -a .../tmp/crazy-stuff
# . .. ... foo
Though this only works in the current directory, because the symbolic links is deleted after each command invokation. Thus ls foo/bar/... won't work this way.
Another ugly hack would be to "override" mkdir such that it populates every new directory with these symbolic links.
See also the comments on the second answer here, particularly Eliah's: https://askubuntu.com/questions/327126/what-is-a-dot-only-named-folder
Much in the same way that when you cd into some directory subdir, you're actually following a pointer that points to that directory, .. is a pointer added by the OS that points to the parent directory, and I'd imagine . works the same way.
Maybe this can be a silly question but I don't figure out how to search in google why in some code I read, it is used to write this way: \\progra~1
What does ~ and 1 mean?
I tried executing in Windows Run the same path but changing numbers and these are the results:
C:\progra~1 -> Opens Program Files
C:\progra~2 -> Opens Program Files(x86)
C:\progra~3 -> Opens ProgramData
C:\progra~4 -> Opens ProgramDevices, a folder I created in C:\
Why? Is this like a Match or something in the Folder names list?
For example a regex like "progra" and then to show the ~1 (First) match in some X order or ~2 (Second) ... etc?
It's a compatability mode with the old (really old) windows 8.3 naming convention. The ~n represents the instance of the name that has the same root characters.
In your example:
Program Files and Program Files(x86) have the same root characters Progra.
Hence one gets progra~1, the next progra~2 etc.
8.3 compatability can be turned off for a disk partition.
Exactly, it's a pattern counter.
Check out also this answer: What does %~d0 mean in a Windows batch file?
You can find more examples of different variables with modifiers here:
https://technet.microsoft.com/en-us/library/bb490909.aspx
(ctrl-f for "Variable substitution")
On a Linux system I have a binary (bin.exe) which needs to read an input file (input.cfg), where the names of other data files (data.txt) are specified. Usually both binary, input file and data files were in the same directory. Now and for organization reasons I need binary file to be in $SOMEPATH/bin and input and data files in $SOMEPATH/input.
I do not know how to do this. If I try
$SOMEPATH/bin/bin.exe $SOMEPATH/input/input.cfg
I get
error, "data.txt" not found
One solution would be to include absolute of relative path of "data.txt" in input.cfg, but the binary does not accept this.
I thought about somehow fooling the binary so that it thinks it is in $SOMEPATH/input, so that I just do
$SOMEPATH/bin/bin.exe input.cfg
and it works, but I do not know whether this is possible. any hints?
(cd $SOMEPATH/input && $SOMEPATH/bin/bin.exe input.cfg)
This is assuming that the program is relying on the current working directory to find the files. If the program is trying hard to find them in the same location as the executable, by consulting /proc/<pid>/exe for example, then you may be out of luck.