Hi John, First, the unix and linux filesystem allows the use of any nonzero character in its filesystem filenames and the c functions open / fopen, symlink. rename, chdir and so on don't care about any tilde. If the open systemcall gets a file which begins with a tilde then it will try to open this filename without any preceding modification.
So the tilde expansion is not really a unix idiom. It is rather an idiom of its unix shells like bash. But beware, the bash treats the tilde as home path not in all cases. Inside of quotes the tilde keeps unaltered. So bedides any cenvenience functionality which can lead to failing code the bash has a very clean way to access files in a unique way. And here is the problem wirh R. The R shell has no quoting mechanism for this use case. It provides the tilde expansion after a string has been defined. In the bash it is the opposite. First the string gets defined ( for instance ~"/abc.txt" would expand to "/home/user/abc.txt" or "~/abc.txt" keeps "~/abc.txt" and that means a directory named '~' with a directory entry named 'abc.txt' inside of it) and after it is defined it keeps consistent and can be passed to every function. Actually R has already a clean string datatype. But by the transition to filesystem operations the expansion takes place. In my opinion at the wrong place. And additionally there exists no quoting mechanism which allows to keep tildes unaltered. It would be better to clear distinguish between a string which is passed to the filesystem calls and some convenience expansion mechanisms. But it is like it is. For my need I created a solution which takes strings unaltered and so I can fulfil my work. And for whom who is interested in it, can take a look: https://github.com/schwidom/simplefs Suggestions are welcome. Kind regards Frank Schwidom On 2019-06-12 12:50:12, John via R-help wrote: > On Wed, 5 Jun 2019 18:07:15 +0200 > Frank Schwidom <schwi...@gmx.net> wrote: > > In reading file names, names with spaces require escaping of the > spaces, and you are using not only a tilde but the space as spell. The > tilde is conventionally read as wild card representing the leading > portion of the file address, which is what you see here: > > The long standing convention in unix and linux is that a tilde is > shorthand for your home directory, just as "./" is the local directory > and "../" is one step back up the directory tree. The output of > path.expand() varies in how your string is constructed: > > 1. > path.expand("ab") > [1] "ab" > 2. > path.expand("a b") > [1] "a b" > 3. > path.expand("a ~b") > [1] "a ~b" > 4. > path.expand("a ~ b") > [1] "a /home/john b" > 5. > path.expand("a ~/b") > [1] "a /home/john/b" > 6. > path.expand("~/a b") > [1] "/home/john/a b" > > Notice that the spaces have an effect on how the tilde is parsed in > the string. The next to last case sees a string with three elements: > "a", the local path, and "b". The last expands the tilde as the "path" > to a hypothetical file "b" in the home directory. In the sixth case the > same behaviour occurs. > > If you read the help for path.expand(), the routine expects > "leading" tildes, which explains the free floating "path in the fourth > example. In the third example, where the forward slash is omitted, the > routine simply treats the tilde as part of a string. > > Also note this at http://www.linfo.org/file_name.html: > > "...file names only use alphanumeric characters (mostly lower case), > underscores, hyphens and periods. Other characters, such as dollar > signs, percentage signs and brackets, have special meanings to the > shell and can be distracting to work with. File names should never > begin with a hyphen." > > The probable "bug" is that none of the programmers imagined that anyone > would use special characters within file names, "legal" or not, (just > not done, don't y' know). In any case the simple solution, if you > really, really need a tilde in a filename, is to avoid setting it off in > spaces, or any other character that could mislead a routine into > treating it conventionally as shorthand for you home directory. > > JWDougherty > > ______________________________________________ > r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
