Hello all,
I am on a Apple. I am trying to use Shell command. I am trying to change the folder I am in using cd, but it does not seem to be working. I can move to other folders in the Terminal on the Apple, but the Shell in Pure data does not seem to work.

Any ideas on what I am doing wrong?

Try [command], which is an actively maintained replacement of [shell]. [shell] is no longer maintained, and that could be the issue.

which extension uses command?

I might have figured out a problem I am running into with this.

So, does ofelia use terminal? If I open ofelia am I also going into a specific directory as well?

If you want to do shell stuff, just install the command external. It's up on deken (Help -> Find externals), just look for "command".

Hey all,
I think I am understanding an issue that I do not know how to resolve.

Does ofelia take over the "terminal" or some other function for Pure Data if created?

So, if I open up one file that uses ofelia. . . to show a score easily. Then shell and command do NOT allow me to move from directory to directory. And in fact, the directory that pure data is stuck on is the program that opened ofelia.

If I do not open ofelia, then I can seem to move from directory to directory. I can essentially use shell or command and use unix commands:

ls & cd to check the directory and move to a directory.

Help

@raynovich Not sure about [command] and [shell] in this case but if you only need to do file manipulation and the like perhaps the [file] object will work in this case? I know [file cwd] does not affect the working directory of [command] so maybe it will not have the issue with ofelia? I don't know much about ofelia.

@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh