If I am referenceing a file (lets say an image file for it to display on a webpage) which is a few folders above, I can write "folder1/folder2/file.jpg". What does it mean if the reference starts with a slash like "/folder1/folder2/file.jpg"?
Leading slash means that the reference is starting from the root directory (absolute reference) vs. the current location (relative reference).
Related
That is, do they take up storage space? Is dot a copy of the current directory? Could I say that dot and double dot are subdirectories of the current directory?
A directory is logically a table used to map names to filesystem objects such as files or directories. Files can have multiple names and can be in multiple directories. The extra directory entries are links to the same file; the file itself is not duplicated. The same is true for directories. The '.' entry is a name which always maps to the directory that it is in. '..' maps to the parent, but in the case of the root directory it maps to itself.
I am trying to download only certain files from a folder. The folder contains thousands of files named:
z_cams_c_ecmf_20160904000000_prod_fc_sfc_120_duaod550.nc
z_cams_c_ecmf_20160904000000_prod_fc_sfc_120_gtco3.grib
z_cams_c_ecmf_20160904000000_prod_fc_sfc_000_aod550.nc
etc.etc.
I only want those that end in duaod550.nc and aod550.nc
Is there a way to isolate this string from the filename? Unfortunately I cannot use the .nc because there are other files that have this extention and I don't need them.
Looks like what you need to do is use the a wildcard in the ftp command in matlab. From the help
mget(ftpobj,contents) retrieves the file or folder specified by contents from an FTP server into the MATLAB® current folder.
contents --
Character vector enclosed in single quotation marks that specifies either a file name or a folder name. Can include a wildcard character (*).
filelist=mget(ftpobj, '*duaod550*')
filelist=mget(ftpobj, '*aod550*')
So, I'm incredibly new to LiveCode and I have an external file in the same directory as the .livecode file called 'words.txt', with english words, each on a new line. I plan to read this file into a variable and then pick a random word from that variable. However, I am stumped as to how I must find the file path and insert this into the syntax required for me to do this. My code is as follows:
put url ("binfile:" & filePathGoesHere) into dictionary
replace crlf with lf in dictionary
replace numToChar(13) with lf in dictionary
put any line of dictionary into randomword
The file path is supposed to be inserted into the code at filePathGoesHere. Once the program is compiled I will be moving it and its resources around a bit (from computer to computer), so, beyond the text file staying in the same folder as the compiled program, the file path will change. What extra code would I need to add to make this work, if the folder the compiled program and the txt file is in is called "MyProgram"?
Help is much appreciated, and if further specification is required I can provide it. I also have a folder called "resources" if moving it there can help.
If the stack you're building is for your own use, you can place external files anywhere, but if you're going to deliver your stack to other users, you need plan where you external files are going to be placed, and how.
An easy way to determine the path to a file that sits immediately outside your stack is using the stack's filename:
put the fileName of this stack into theFilePath
set the itemDel to "/"
put "words.txt" into the last item of theFilePath
Now theFilePath variable will an absolute path reference to your external file. If the file is placed inside a folder "TextFiles" you can do this:
put the fileName of this stack into theFilePath
set the itemDel to "/"
put "TextFiles/words.txt" into the last item of theFilePath
If you're going to deliver your stack to other people, you should write your external file/s into a common system folder, or you need to use an installer to define where your files/folders will be placed. Common folder paths are found using the specialFolderPath function:
put specialFolderPath("Documents") into the theFolderPath
A somewhat recent addition to LiveCode is a "Resources" folder -- specialFolderPath("Resources") -- which can be handy for delivering on desktop and mobile platforms. Also, keep in mind that few of these folders allow writing to existing files contained in them for security reasons. "Preferences" and "Documents" are two examples of folders where you can change the contents of files.
The LC dictionary contains details of each of the folders.
If you use the file: scheme instead of bindle: LiveCode will automatically convert end of line characters to LF, so that step may not be necessary. (Although you might need it if you are reading a text file produced in native Windows encoding on a Mac.) You don't even necessarily need to read it into a variable. You could do this:
put any line of URL ("file:" & specialFolderPath("resources") & "/words.txt") \
into tRandomWord
The ls -ai command shows that . and .. have their inodes the same as the current directory and parent directory, respectively.
What exactly are . and ..?
Are they real files or even hard links? But as I have known, it's not allowed to create a hard link to a directory.
. represents the directory you are in and .. represents the parent directory.
From the dot definition:
This is a short string (i.e., sequence of characters) that is added to
the end of the base name (i.e., the main part of the name) of a file
or directory in order to indicate the type of file or directory.
On Unix-like operating systems every directory contains, as a minimum,
an object represented by a single dot and another represented by two
successive dots. The former refers to the directory itself and the
latter refers to its parent directory (i.e., the directory that
contains it). These items are automatically created in every
directory, as can be seen by using the ls command with its -a option
(which instructs it to show all of its contents, including hidden
items).
They are special name-inode maps which do count as hard-links (they do increase the link-count) though they aren't really hard-links, since, as you said, directories can't have hard-links. Read more here: Hard links and Unix file system nodes (inodes)
. represents the current directory that you are using and
.. represents the parent directory.
Example:
Suppose you are in the directory /etc/mysql and you wanted to move to the parent directory, i.e. /etc/. Then use cd..:
/etc/mysql> cd ..
And if you wanted to set the path of one file in the current directory bash file, use . with file name like this: ./filename
They are not hard links. You can more think of it like a shorthand for this directory (.) and parent of this directory (..).
Try to remove or rename . or ... Then you understand why it is not a hard link.
I would like to know how an absolute path of a symbolic link can be converted to relative based on a given directory (that includes the linked file) in c language on linux (Ubuntu) OS.
I thought searching for the sub-string of the relative path, but what if it already exists higher in the folder's hierarchy?
Here is a more specific description of what I want to do:
Relative path:
folder/folder1/folder2
Absolut path:
/home/giorgos/Desktop/folder/folder1/folder2/a.pdf
changed to
/home/giorgos/Desktop/myfolder/folder1/folder2/a.pdf
Obviously I cant' simply search for and replace "folder/", consider this case:
/home/giorgos/Desktop/folder/folder/folder/folder1/folder2/a.pdf
It can be searched both forwards and backwards and if replaced it still gives a wrong output
Only if I knew the relative path I could search the absolute backwards and replace it, then the output would be correct:
/home/giorgos/Desktop/folder/myfolder/folder/folder1/folder2/a.pdf
Converting a path to relative is a matter of first seeing how many base atoms are shared between the two paths, and then inserting ../ to navigate backwards up the tree before navigating down the correct branch. IE going from: /foo/bar/some/path to /foo/other/path you'll first see that they share /foo, to navigate upwards to that point you need 3 ../, turning the relative path into /foo/../../../other/path . There's a boost::filesystem example for C++ here , save for the C++ & boost::filesystem the same can be done in C.
I'd be seriously tempted to make the decision, if I were writing this tool, that absolute symbolic links should have the same value when moved somewhere else in the filesystem -- the user wanted a very specific file. And, relative symbolic links should have the same value when moved somewhere else in the filesystem -- the user wanted the links to work regardless of where the directory tree was rooted.
But if the two types of links were intermixed, then you'd have some more work to do -- which is where I assume you are now. (Unix programs are often not that forgiving about guessing a user's intent; if you just readlink(2) and symlink(2) exactly what the filesystem says, your program will never be surprising.)
rsync(1) might have some source code you can use -- or at least learn from. The --safe-links command line option causes rsync to ignore absolute symbolic links and relative symbolic links that point outside the trees it was instructed to copy. This isn't canonicalizing paths to relative as you wish but it may provide sufficient code for discovering which links point outside the directory tree in question.
Slightly related; the Linux-specific symlinkat(2) system call may make it easier for you to create your symbolic links. (The family of ...at() system calls are something like providing a process with multiple "current working directories" without forcing you to make all the fchdir(2) calls yourself.)
Well at first I didn't consider the following as important information, but with the help of a function I found out the absolute path to the original and copy directories.
This way I could finally get the original's folder "relative path" (path starting from original folder) change the root node of the dir's tree name to the copied folder's then get the absolute path of the copied folder and append the copied "relative path" and that was it!
realpath(directory,absolutePath);
This is what my code looks like :
readlink(A[i].str, oldLink, NAMESIZE);//A is the struct I keep the paths to directory entries
k=0;
j=strlen(absolutPath);
while(oldLink[j]!='\0')
{
fixLink[k]=oldLink[j];
j++;
k++;
}
strcpy(tmpLink,newAbsolutPath);
strcat(tmpLink,fixLink);
symlink (tmpLink,tmpPath);//tmpPath is the name of the link, tmp link is the absolute path to the actual file
//tmpPath is built almost the same way
So far it runs without any bugs