In some documentation, I have gotten the instructions to write
SERVER_PATH\theme\
When I check _SERVER["DOCUMENT_ROOT"] from php info, it's
/storage/content/75/113475/frilansbyran.se/public_html
this renders of course
/storage/content/75/113475/frilansbyran.se/public_html\theme\
this looks really weird to me what's the difference anyway which should I use? (unix-server)
Using backslashes is typically the windows way of paths, eg:
C:\Windows\System32
Forward slashes are usually used in Unix systems ala:
/usr/home/jdoe
If you are using a Unix-server I would stick to the forward slashes (/'s), though many times in in practice the system is smart enough to use either interchangeably
Path separator in Unix is /. The backslash \ is used to escape some special characters (incl. space) in the directory and file names.
The backslash \ is used as a path separator in the Windows world. It is possible, that 'some' documentation uses it.
If you are on Unix, use slash / only.
In *nix, forward slash [/] is used as the directory separator, so I would use that.
Back slashes [\] are used as directory separators on Windows systems.
To add to what others have said:
in URLs on the web, the Unix-style forward-slash / is always used; a backslash won't work in most situations.
in Windows filepaths, the forward-slash is an acceptable alternative to the backslash, so although it's not the normal way of writing it, C:/Foo/Bar will work.
So if in doubt, use the forward slash.
Related
I have a application. My application must run in Linux and Windows. I must write in main gradle-file any command. These commands content slash ("/" or "\"). How can I get what slash ("/" or "\") use (in language groovy)?
If you work with Java, you can freely use '/' as a file separator. java.io.File will handle it for you. See similar SO question.
Gradle's file('Some\slashy/path') is a shorthand for
new java.io.File("Some\slashy/path"), and so deals with slashes correctly too.
You should use java.io.File.separator instead of hard-coding it.
Usually Windows process "/" correctly. Just try
I'm working on a C application that has to walk $PATH to find full pathnames for binaries, and the only allowed dependency is glibc (i.e. no calling external programs like which). In the normal case, this just entails splitting getenv("PATH") by colons and checking each directory one by one, but I want to be sure I cover all of the possible corner cases. What gotchas should I look out for? In particular, are relative paths, paths starting with ~ meant to be expanded to $HOME, or paths containing the : char allowed?
One thing that once surprised me is that the empty string in PATH means the current directory. Two adjacent colons or a colon at the end or beginning of PATH means the current directory is included. This is documented in man bash for instance.
It also is in the POSIX specification.
So
PATH=:/bin
PATH=/bin:
PATH=/bin::/usr/bin
All mean the current directory is in PATH
I'm not sure this is a problem with Linux in general, but make sure that your code works if PATH has some funky (like, UTF-8) encoding to deal with directories with fancy letters. I suspect this might depend on the filesystem encoding.
I remember working on a bug report of some russian guy who had fancy letters in his user name (and hence, his home directory name which appeared in PATH).
This is minor but I'll added it since it hasn't already been mentioned. $PATH can include both absolute and relative paths. If your crawling the paths list by chdir(2)ing into each directory, you need to keep track of the original working directory (getcwd(3)) and chdir(2) back to it at each iteration of the crawl.
The existing answers cover most of it, but it's worth covering parts of the question that wasn't answered yet:
$ and ~ are not special in the value of $PATH.
If $PATH is not set at all, execvp() will use a default value.
This question already has answers here:
Difference between forward slash (/) and backslash (\) in file path
(7 answers)
Closed 6 years ago.
What is the difference in using a forward slash and backslash in navigating file systems. Also what is the difference between ./ and ../?
Well, in most languages backslashes need to be escaped in string literals, slashes do not. Further backslashes only work on Windows, while slashes work pretty much everywhere.
On the other hand, when passing path names as arguments to Windows programs, using slashes might not work because many Windows programs use slashes to signify command line flags, so you need to use backslashes.
On . vs. ..: . is the current directory, .. is the parent directory.
Microsoft operating systems (e.g. DOS and Windows) use backslashes (\), UNIX-based operating systems (e.g. Linux) use slashes (/).
The dot (.) means the current working directory, it's like saying "here". The double dot (..) means the parent directory.
The difference between slash and backslash in Windows are from my tests at least non-existing, but I believe that in earlier editions they used backslash. UNIX systems uses slash.
The difference between ./ and ../ is that ./ represents the position in the hierarchy where you are standing while ../ is the parent directory.
Backslash is used for:
File names in DOS and Windows, e.g. D:\documents\office, C:\java\jdk
escape sequences in C, Unix, and other languages/systems that borrow the same syntax (C++, Java, etc.). For example, \n means newline and \t means tab.
Forward slash is used for:
File names on Unix (and Mac OS X, since it is derived from Unix), e.g. /cs/student/jsmith/cs8/lab00, /Users/Shared/cs8/cTurtle.py.
Web addresses (URLs), such as http://www.cs.ucsb.edu/~pconrad/cs8.
Dividing in many programming languages, e.g. battingAvg = hits / atBats;
Is putting a space in a directory name still a big deal? I've been doing some reading, but all the articles are from the early 2000s. Is it a problem now?
For those who don't get what I mean: public_html/space directory/index.html
If this is still an issue, why shouldn't I use spaces when naming files and directories?
Spaces in URLs are still special characters that need to be escaped or encoded (either a + or %20).
Well, I am still crossing fingers when executing external processes (from ant or Java's ProcessBuilder for example). If you just pass this dir to the external process within the command - it may break apart in two arguments which is clearly not what you want.
Some quoting and minding the spaces is still required in some usecases.
I'm not asking about general syntactic rules for file names. I mean gotchas that jump out of nowhere and bite you. For example, trying to name a file "COM<n>" on Windows?
From: http://www.grouplogic.com/knowledge/index.cfm/fuseaction/view_Info/docID/111.
The following characters are invalid as file or folder names on Windows using NTFS: / ? < > \ : * | " and any character you can type with the Ctrl key.
In addition to the above illegal characters the caret ^ is also not permitted under Windows Operating Systems using the FAT file system.
Under Windows using the FAT file system file and folder names may be up to 255 characters long.
Under Windows using the NTFS file system file and folder names may be up to 256 characters long.
Under Window the length of a full path under both systems is 260 characters.
In addition to these characters, the following conventions are also illegal:
Placing a space at the end of the name
Placing a period at the end of the name
The following file names are also reserved under Windows:
aux,
com1,
com2,
...
com9,
lpt1,
lpt2,
...
lpt9,
con,
nul,
prn
Full description of legal and illegal filenames on Windows: http://msdn.microsoft.com/en-us/library/aa365247.aspx
A tricky Unix gotcha when you don't know:
Files which start with - or -- are legal but a pain in the butt to work with, as many command line tools think you are providing options to them.
Many of those tools have a special marker "--" to signal the end of the options:
gzip -9vf -- -mydashedfilename
As others have said, device names like COM1 are not possible as filenames under Windows because they are reserved devices.
However, there is an escape method to create and access files with these reserved names, for example, this command will redirect the output of the ver command into a file called COM1:
ver > "\\?\C:\Users\username\COM1"
Now you will have a file called COM1 that 99% of programs won't be able to open, and will probably freeze if you try to access.
Here's the Microsoft article that explains how this "file namespace" works. Basically it tells Windows not to do any string processing on the text and to pass it straight through to the filesystem. This trick can also be used to work with paths longer than 260 characters.
The boost::filesystem Portability Guide has a lot of good info.
Well, for MSDOS/Windows, NUL, PRN, LPT<n> and CON. They even cause problems if used with an extension: "NUL.TXT"
Unless you're touching special directories, the only illegal names on Linux are '.' and '..'. Any other name is possible, although accessing some of them from the shell requires using escape sequences.
EDIT: As Vinko Vrsalovic said, files starting with '-' and '--' are a pain from the shell, since those character sequences are interpreted by the application, not the shell.