mainThe GNU Bourne-Again SHell - Support: sr #108576, Bash should support file:// URLs...


sr #108576: Bash should support file:// URLs as regular paths

Submitter:  Dan McDougall <riskable>
Submitted:  Tue 20 May 2014 01:25:25 PM UTC
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Thu 01 Jun 2017 10:22:32 PM UTC, comment #1: 

Regarding the "edge case", a file or directory name on Linux (and all Unix, I think) can't contain "/". Underlying syscalls like open() have no provision for "escape" syntax to create or open files with slash as part of the name.

That said, however, there's another "edge case":
$ mkdir file:
$ echo snork > file:/something
$ cat file://something  # ./something or ./file:/something ?

"file:" is a valid directory name, and if two consecutive slashes appear in a path they effectively collapse into one.

One additional problem with the feature as described is that it becomes inconsistently-applied. If it's only supported in the built-in commands, what happens when you try it on a non-built-in command? Suddenly it doesn't work. "Why did it work there but not here?" That, IMO, does not improve the user experience.

To get around that, file:// URL decoding could become part of the file matching syntax, like wildcards and other globbing patterns. That would mean that any (unquoted) "word" on a shell command line that started with "file://" would be URI-decoded to produce a file path. But that would be problematic for various reasons:

For starters, there's still that edge case, "file:///whatever" is a potentially valid, actual Unix path name.
Additionally, this also means that anyone passing a file:// URI to a program that expects a file:// URI now needs to quote it, or the shell will gleefully convert it to a Unix-style path on their behalf, potentially breaking people's scripts.

So personally I don't think it's a good idea to provide this as new syntax or new built-in behavior. Just explicitly decode the URI with command substitution:

$ cd $(uri-decode file:///usr/bin)   # Requires a suitable "uri-decode" command of course...

George Caswell <tetsujin>
Tue 20 May 2014 01:25:25 PM UTC, original submission:  

It occurred to me today that when copying and pasting a file from a graphical tool into a terminal it will almost always be pasted as file:///some/path instead of just /some/path.  I would fault the GUIs for this incompatibility but really, file:// URLs have been a standard for quite some time now.

I propose that support for file:// URLs be added bash's built in commands such as 'cd', 'exec', etc and similar path-using capabilities (e.g. $PATH, '-f' in conditionals).  Examples of how it would work:

cd file:///usr/bin # Same as cd /usr/bin
cd file://~/bin    # cd ~/bin
exec file:///usr/local/bin/foo # exec /usr/local/bin/foo
file:///bin/ls # Execute /bin/ls
[[ -f file:///etc/passwd ]] && echo "/etc/passwd exists"

Really, the only thing that needs to happen from the shell's perspective is the removal of the leading 'file://' part of the string.  It would be extra awesome if file:// URLs worked in the $PATH variable as well but that would just be "extra credit" since the most common use case would be simple things like 'cd' and execution.

To handle the edge case where a file or directory's name (in the current working directory) starts with "file://" it would require escaping anyway so that situation should be easily distinguished:

touch 'file://'
[[ -f file:\/\/ ]] && echo "the file, 'file://' exists"
mkdir 'file://' && cd file:\/\/

The purpose of this wish is simply to improve the user experience.  There's no absolute technical reason for this feature to exist other than, "it would be nice" and perhaps make it easier for certain kinds of external programs to interact with  the shell.

Dan McDougall <riskable>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by chet (Updated the item)
  • -email is unavailable- added by tetsujin (Posted a comment)
  • -email is unavailable- added by riskable (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-17 chet StatusNone Wont Do

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code