Terminal commands problem with $PATH?

coxorange wrote:

When I try to run the install command again, I get "Tool 'vrchat.vpm.cli' is already installed." in green text. I therefore assume that the installation did work.

So why are you posting about it then?

I didn't remember what the output was, so I uninstalled and then reinstalled the tool. It looks like while the installation itself did succeed, it ran into an issue with the $PATH variable and is suggesting I run further commands to fix the issue:

#####

"Skipping NuGet package signature verification.

Tools directory '/Users/[USERNAME]/.dotnet/tools' is not currently on the PATH environment variable.

If you are using zsh, you can add it to your profile by running the following command:

cat << \EOF >> ~/.zprofile

# Add .NET Core SDK tools

export PATH="$PATH:/Users/[USERNAME]/.dotnet/tools"

EOF

And run `zsh -l` to make it available for current session.

You can only add it to the current session by running the following command:

export PATH="$PATH:/Users/[USERNAME]/.dotnet/tools"

You can invoke the tool using the following command: vpm

Tool 'vrchat.vpm.cli' (version '0.1.28') was successfully installed."

#####

Ah! I see the problem. You actually didn't follow those instructions. And I missed it too when you posted your path. What you added to your path was this:

~/.dotnet/tools

That won't work. The "~" character is a shell interpreter artifact. It won't work as part of the path. And the instructions aren't that good either. Change this part of your path to this:

$HOME/.dotnet/tools

And that might fix it.

Also, the instructions say to use .zprofile. These dotfiles can get complicated really fast. I would recommend keeping everything in .zshrc for convenience.

Well, the guide I'm following is specifically designed for people who want to install the VRChat tools on macOS. In fact, I only found the guide because the VRChat support linked me this page https://vcc.docs.vrchat.com/vpm/cli/#mac-setup when I asked about installing on macOS.

To quote the text just before that anchor, "The only fully-supported platform at the moment is Windows 10".

This is pretty standard for open source tools. Never assume that anything will run on a Mac. If it does claim Mac support, there's a good chance someone added some hacks in 2009 and no one has touched or tried it since.

But I think changing "~" to "$HOME" should fix it for you - or at least get you to the next blockage.

(blew past the 5000 character limit on this one)

the "dotnet-cli-tools" file contains: "~/.dotnet/tools"

That's the one.

Unfortunately, this complicates matters somewhat. For one thing, these are files owned by root. Don't try to edit them with TextEdit. BBEdit might be able to handle them. The normal way of editing these files would be using "sudo vi /etc/paths.d/dotnet-cli-tools".

Also, this is a special Mac-only "path_helper" architecture. It isn't the same as the zsh dot files. You can't replace the "~" with "$HOME" in this file. You'll have to use the full path to your home directory, something like "/Users/[USERNAME]/.dotnet/tools" (without the quotes). In truth, this file is wholly inappropriate for any path inside a home directory. It should only be used for globally accessible paths. But if the people who designed this didn't know that "~" wouldn't work, they probably wouldn't have known this either.

coxorange wrote:

After running "dotnet tool install --global vrchat.vpm.cli", when I try to run the "vpm install templates" command I get the above error. (Yes, I've confirmed that the install worked.)

I'm going to go out on a limb here and say the install didn't actually work.

I found this article https://iboysoft.com/howto/mac-command-not-found.html suggesting to change the default path using "export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"", but I have no idea if this command might mess up other things

Most definitely it will mess up other things.

So I ran "echo $PATH"&nbsp; to see what it's currently set to, and got this mess of a path:

"/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands"

Surely that can't be the correct path, can it?

That looks correct. You're still running Sonoma, so the default path of:

/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin

is relatively short. It's a bit longer on Tahoe. 😄

And it looks like the .NET additions are correctly set.

Apologies if this is something straightforward, |'ve only used Terminal very rarely so far.

Yes and no. It looks like that "vpm" tool didn't get installed correctly. I don't know how that works. It's part of .NET, which nobody in the Apple world knows anything about.

I don't see anything you're doing wrong. When I first saw your post, I assumed it would be yet another "Homebrew corrupted my system" post, but it's not! You're not using Homebrew. That makes sense. You seem to be much more savvy that most folks I see these days. You included direct links to instructions you were following. You're making rational assessments about the irrational complexity of your PATH, which, alas, Apple never did. And you're not using Homebrew!

Can you provide more detail about what happens after you ran "dotnet tool install --global vrchat.vpm.cli"? Did it report any kind of error message? Or any output?

Did you try to open a new Terminal window afterwards? After making changing like installing tools or modifying your environment, you will need to open a new shell via a new Terminal window to see the new behaviour.

Pro tip: never close the old Terminal window. If something gets scrambled and your new Terminal is unusable, you'll still have an old Terminal window where you can try to fix it.

If that doesn't fix it, then you'll have to contact the developers of that VRChat tool. They may have never tried it on a Mac. It's a .NET plugin, not a system tool. So you would need detailed knowledge of how .NET works internally. In this respect, it's very similar to the CPAN system in Perl, or the PIP system in Python. But unlike those systems, .NET has relatively little use outside of Windows.

coxorange wrote:

The "dotnet" file contains: "/usr/local/share/dotnet", and the "dotnet-cli-tools" file contains: "~/.dotnet/tools"

There is another alternative for you.

You can use the "nano" command line text editor (actually it is "pico"), but it will do the job without the learning curve of "vi" & "vim". It is fine for something this simple. Once "nano" is launched, you use the arrow keys to navigate. Edit the text, then press Control + X to save & quit. You will be prompted to confirm the changes by typing "Y" or "N" ("Y" for yes & saving the changes), then you will be asked to confirm the name of the file...press the "Return" key if the name is correct (it should be unless you accidentally pressed a key while this prompt is visible).

With "nano" the messages appear at the bottom of the editor window along with some common key combinations such as "Control + X" shown as "^X" where the carrot character "^" indicates the Control key.

To use "nano" to edit the "/etc/paths.d/dotnet-cli-tools" file use following command to open that file in "nano":

sudo  nano  /etc/paths.d/dotnet-cli-tools

Double-check the file name is correct. I believe that is the file you mentioned.

The "sudo " part will prompt you for your admin password. Nothing will appear on the screen as you type the password. Press the "Return" key to submit the password.

You may want to practice on creating a text file using nano in your own home user folder before going to change the "dotnet-cli-tools" file.

nano  ~/Documents/NANO-Test.txt

I agree with @etresoft BBEdit is a very nice app. Even the free version has a lot to offer. Unfortunately I've never been able to learn "vi" or "vim", although I may have to since nano/pico on macOS is so basic & cumbersome compared to their Linux versions.

coxorange wrote:

So you're suggesting I run the following commands, with the "~" in the first line being replaced with "$HOME" and ".zprofile" also in the first line being replaced with ".zshrc"?

cat << \EOF >> $HOME/.zshrc

# Add .NET Core SDK tools

export PATH="$PATH:/Users/[USERNAME]/.dotnet/tools"

EOF

Have I understood you correctly? I'm trying to keep up, but am feeling a bit confused. Sorry.

If so, I'm not sure if they're meant to be pasted and run as 1 block, or if each line should be run in sequence as a separate command?

No. Don't run those commands. From the path you listed in your original post, the incorrect path has already been added. I guess one of those other installation script did it for you. But now, you need to fix it.

I'm not sure which file it added the path to. Check .zprofile and .zshrc. You'll need to edit these files with a real text editor. I recommend BBEdit. The old-school "vi" tool is built-in, but it can be a bit difficult to use if you aren't familiar with it. But if you plan to do a lot of work on the command-line, then vi (or "vim") skills would be very useful.

There are a few other files that the path could be specified in. Hopefully it's in one of those two above.

I have no idea what ".zprofile" or ".zshrc" is, or what they're used for, so I'll have to take your word that one is preferable to the other.

These are colloquially referred to as "dot files". They are files that start with a dot. This dot makes them hidden by default. It's very common for command-line tools to create these hidden dot files and dot directories. You should also already have a ".dotnet" dot directory. Lotsa dots there.

Though, if I've understood what that first line is doing correctly, it accesses a hidden file called ".zprofile" (or ".zshrc" if I change it) located within the home folder, and then concatenates ("cat" (?)) what follows in the next line (starting with "# Add"), to what's already in that file. But when I look at the hidden files in my home folder, I don't have either of these files. The only files beginning with ".z" I have are ".zsh_history" and a folder called ".zsh_sessions".

Those instructions are for what we call "the great unwashed". They are quick-n-dirty instructions to feed people so that no one ever needs to learn how any of this work. Then, when something doesn't work properly, which happens 98.732% of the time, those poor folks are totally lost.

When normal Unix people make change to their dot files, they never, ever use "cat". The shudder at the idea. These are just text files. Open them with a text editor and make changes. Maybe even keep all the various commands organized in some fashion.

Unfortunately, if you only have those two zsh dot files, then the path has probably be specified using a different method. Do you have any files in /etc/paths.d? If so, what are they?

I noticed that the dotnet sdk installer seems to add a "dotnet" file to that location. But it didn't look like it wrote that ".dotnet" folder to that file. But who knows what the actual installer and the template installer did?

I assume this is normal and not an issue? Again I'm only guessing at what these commands are doing based off of other coding experience I have.

Your guesses are correct. Those "cat" commands are common (but bad) practice for such projects. But if this project isn't using those files, you'll have to track down where it adds that path so that you can fix it.

coxorange wrote:

I found this article https://iboysoft.com/howto/mac-command-not-found.html suggesting to change the default path using "export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin""

That looks like a very basic PATH that you might use with a generic Unix or Linux system. These days, the macOS PATH seems to be a bit more involved. Under Sequoia, I see

% echo $PATH

/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin

which, breaking it down, has these components

/usr/local/bin

/System/Cryptexes/App/usr/bin

/usr/bin

/bin

/usr/sbin

/sbin

/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin

/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin

/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin

/Library/Apple/usr/bin

I bet if you were using a version of Mac OS X / macOS before Catalina, you'd find that its default PATH had none of the boldface entries (with the possible exception of /Library/Apple/usr/bin). (Catalina and Big Sur are where Apple really started hardening macOS beyond the level of a generic Unix system – where Apple introduced the concept of a System Volume or Sealed System Volume.

On my Mac, the three …/bootstrap/… directories do not exist. Given the "bootstrap" name, it seems plausible that the system creates them as needed and then deletes them as soon as it is finished using them.

coxorange wrote:

If something went wrong during installation, can't I try to uninstall the VRChat tools using "dotnet tool uninstall --global vrchat.vpm.cli", and then run the installation command again with the proper path this time? Or do you think it's an issue within the installer's code itself, which I would not be able to effect during a re-install?

Nothing went "wrong" per se. The installer functioned as designed. But the design was faulty. If you attempt to re-run the installer, or maybe even update, it will likely break your path again. Ideally, you should report this problem to the maintainers.

Keep this in mind once you get the path fixed. There's an excellent chance that something else won't work.

I don't have either of these files in my home folder, and doing a deep search with Find Any File also did not reveal any files matching those names.

You don't need to do a deep search. They would only be in your home directory.

*not technically true. Some of these files can be in /etc. One of the problems with these things is that it almost always convenient to gloss over the more arcane technicalities. And they write an installer that uses one of them.

Would Text Edit suffice for making this one correction once I've found the file?

<wincing> Maybe? TextEdit has two modes. It can work in plain text and rich text mode. I don't know if it would be safe to try TextEdit. I don't know if there's an easy way to inadvertently change a text file format. There's a greater risk of scrambling permissions and ownership as those usually have to be very precise for these Unix tools. But TextEdit is a GUI tool with no concept of precision. If it follows standard Apple document-based app practice, then it will try to create temporary folders in places it can't and try to completely overwrite the old file. The chances of it maintaining those delicate permissions and ownership is not good.

*TextEdit is one of Apple's example apps for how document-based apps are supposed to work.

At this time I don't intend to get into command-line work beyond getting the VRChat packages installed and working. Though I'll keep BBEdit in mind if I do need a more coding-oriented text editor, thanks for the tip!

Wrong answer. Get BBEdit. Thank me later.

But to be pedantic, the ideal editor in this case is vi (technically vim on macOS). It's really not that difficult to use. You just have to get used to command mode vs edit mode.

Indeed I do, and it contains a "tools" folder, which in turn contains the "vpm" Unix Executable File (installed by running "dotnet tool install --global vrchat.vpm.cli" I assume). The ".dotnet" folder also contains several files starting with "10.0.100", which I assume are used by .NET SDK 10 (which I have installed for unrelated reasons), but there are no files starting with "8.0.419" (which is the .NET SDK version the VRChat guide said their tools need).

Not sure if this means anything (probably not, as I have verified with "dotnet --list-sdks" that both versions are installed); just thought I'd mention it in case it's a clue.

I have no clue about any of that. I'm not familiar with how those tools work with their internal runtimes. But this might be something you'll have to learn if you're going to use them.

*One of my favourite experiences was working for an org that had no idea about such things. Their software was crashing. They were so convinced that their work was so Big and Important that they must be running out of RAM on their servers. I kept asking them to help me dig into this code as I wasn't familiar with it and they kept brushing me off. So they spent $100k on 5 massive servers with 1 TB of RAM each. Software kept crashing. Finally they relented. Took me 5 minutes to figure out the problem was one of these multi-versioning systems and they were simply running an early, buggy version of one tool. Don't be them.

I was unsure where "/etc/paths.d" would be located

That's the path. In Terminal, just do:

cd /etc/paths.d

I've discovered a folder by that name at "Macintosh HD/private/etc/paths.d". Is this the correct folder?

Yes and no. There is no "Macintosh HD/private/etc/paths.d". The path is /etc/paths.d

*Did I mention how complicated this stuff can be on a Mac? The path is also /private/etc/paths.d and /System/Volumes/Data/private/etc/paths.d, but it's better to just refer to it as /etc/paths.d. They're all just pointers to the same actual directory.

Once you know your path you can navigate around using the cd command. e.g. if you're user account is eric and you're in eric then

ls 

will show you the directories and

cd Desktop 

will change the path to desktop if you're in your user area. If not then it will be

cd ~/Desktop

cd.. 

changes up one directory.

You can change the default path by editing the .zshrc file in your user directory. It's hidden, hit

cmd shift . 

to toggle hidden files. Edit it with text edit (or your favourite editor but not a word processor) and add a cd command to it. e.g.

cd ~/Desktop  

will change it to your Desktop directory as default.

Terminal commands are case sensitive. cd ~/desktop won't work. Nor will CD ~/Desktop.

~ means your user directory.

Having said all that, there's something else going on cos you shouldn't have to be in the "right' directory to run commands, but that's not my bailiwick and hopefully someone else will be along shortly.

Please stop what you are doing, create a new login, and experiment there. Working in your own live main login and home directory is harder to clean up mistakes, and risks your data not already backed up. Working in a test login can be deleted and recreated to reset (most, not-sudo) errors. (Once you’re better with Terminal, sure. But for now, learn in a test login. And I’ll still use a test non-admin login myself when I’m poking at what might be in-progress apps or code. Easier to pull the big chrome handle and flush it all away, if things go sideways.)

As for the dotnet error, the Microsoft runtime is not installed or not installed correctly, or you didn’t log out and log back in to pick up the path. (Or there’s maybe a bash dependency here somewhere?) Get the .NET giblets installed per the Microsoft .NET SDK 8.0 directions and the Github .NET runtime site, log out, and back in. See if the dotnet command now works.

Then move on to getting Unity going.

Update your macOS to 14.8.5, too.