As we all take changing directories with “cd” for granted, we would expect there to be a file called “cd” somewhere in the filesystem. I have searched and searched for this elusive file and have returned empty handed. This command is either higher level than a file, as in an alias variable somewhere, or lower level, as in an internal function of bash or something. Perhaps I made an error in my query. Please advise. It seems Shorcuts wasn’t lying when it told me this file doesn’t exist.
Actually a Bourne Shell Builtin.
1 Like
Isn’t bash == Bourne Shell ?
Bash == B ourne- a gain sh ell (Bash (Shell) – Wikipedia) Unix-Shell – Wikipedia )
if you invoke bash with /bin/sh, it behaves like a Bourne Shell, and only the Bourne Shell built-ins are available.
I see. OK, let’s just say “cd” is a builtin of our default shell then. 
There is a good reason the cd command is not an executable.
What it does is change the current directory of bash. If it was running as a separate process, how could it do that? You can’t just change the current directory of another process under its feets.
So, cd just tells bash to change its own working directory. It’s one of the few commands that cannot be implemented in other ways than builtins. (there are other commands which are builtin only for optimization purposes).
2 Likes
So to get Shortcuts to run the bash cd(), it would have to be implemented in Shortcuts.
You mean chdir() from <unistd.h>, right?
I think an extra field should be provided for working folder in the Shortcuts window. If there is something, Shourtcuts should try to chdir() into it and if it succeeds, the program with their arguments should be started here.
But i’m just using my imagination, maybe it makes no sense.
1 Like
But you wouldn’t need either field if it opened emacs instead. J/K. I like this idea. Simple and it seems intuitive to me, at least in theory.
But actually it should looks like this: Shortcuts should set up the environment, change to the working folder and execute the program there.
In should be clear, we are talking about 2 different problems/tasks here:
- Shortcuts doesn’t sets up the environment variables for the running program, so it have no $HOME, some Qt based program had/have? problem with this AFAIK
- Shourtcut should provide a way to adjust the working folder.
What does emacs have to do with this?
I would prefer if the working directory did not matter for apps. When you start them from Tracker they run in the home directory.
There are exceptions but we already cover them:
- Starting Terminal, where the working directory is a central notion. In that case, it deserves to be a command line argument, not something in the environment (the same could be done for Tracker, you can do it already using the open command on a directory)
- Apps operating on specific directories, in that case we have tracker add-ons (which can also have shortcuts)
Besides this, it makes little sense to have a specific “working dir” feature in the Shortcuts app. This is used too rarely to deserve its own field in the app, I think.
Maybe xicon could be used for some extra use cases?
5 Likes
It does make sense, however I think there might be a more elegant way to do so. I like waddlesplash’s idea that shell commands should just run as entered in the text entry in Shortcuts. I’ll be poking around. As it is, Shortcuts seems to do everything from “/”.
I was joking about using emacs as a replacement for the entry field. Kitchen sink and all that. I’m a vi guy, so it’s definitely just a joke.
A little late updating this thread. The patches have been merged and have been available in the nightlies for awhile.
2 Likes