Terminal - Permission Denied

garage4996 wrote:

star@stars-iMac documents % ls --l

ls: unrecognized option `--l'

usage: ls [-@ABCFGHILOPRSTUWabcdefghiklmnopqrstuvwxy1%,] [--color=when] [-D format] [file ...]

That (cryptic) usage info is intended to show the list of switches available.

Generally:

ls -l

not

ls —-l

This is why </> code insertion matters.

For what can also be a cryptic command syntax description, use the command:

man ls

Bitwarden probably has one, as well:

man bw

In general, some shell commands will use short options and one hyphen, and others use long switches and two hyphens, and most of the latter also support the former. The bw command appears to support long switches, per what has been posted and published.

There are also a few cases where two hyphens with no switch are used as a delimiter, but that tends to be fairly rarely necessary.

Thanks for this wery useful information - after a long time only I got an explanation what thesse [ ] brackets means - thesse are not ordinary brackets ? As I typed ( surely ) something wrong this usage : Ls appeared and thes brackets [] . But as you say thesse are not part(s) of a command - thesse [] is only an instruction or explanation how to use the ls command ? After Ls there are 4 possibilities inside the brackets [] the first one is someting [-@ABCF…… difficult to understand what it can be the second one [ —color …. this is also something to type ls —color as I think The third one [ -D format ] difficult to understand the 4 th one is also not clear [ file ….]

Here is the zsh documentation: https://zsh.sourceforge.io/Guide/zshguide.pdf

As for the bw command syntax past the website and the man page (if any), ask Bitwarden support for help.

garage4996 wrote:

star@stars-iMac ~ % ~/bw create attachment --file "~/documents/mailfence recovery_codes.txt" --itemid 2d6d3935-324b-9ea0-819b-ac700021d0a5 

? Master password: [hidden]

Cannot find file at /Users/star/~/documents/mailfence recovery_codes.txt

star@stars-iMac ~ % 

As you see Cannot find file .

And as can be seen from the error, Bitwarden does its own thing, and isn’t honoring the ~ notation here.

Specfically:

Cannot find file at /Users/star/~/documents/mailfence recovery_codes.txt

That syntax won’t work. You can try that path yourself with ls, and will find it won’t work.

It appears file parser within the Bitwarden tool might need some help.

The workaround is either a relative path, or an absolute path from the file system / root.

Probably:

“/Users/star/Documents/mailfence recovery_codes.txt”

You’re also not using the correct case on that filename. You can get away with that error here, but incorrect case usage will cause problems in other zsh contexts, and will cause issues with zsh switches and commands.

it will take some time to learn more about zsh, about its error messages, about app differences and errors, and for you to review the Bitwarden docs and potentially to discuss that bw tool with Bitwarden support.

Quit Terminal.app, temporarily rename your zsh login files, and try launching Terminal.app again.

Use the Command-Shift-Period toggle in Finder to enable hidden-file viewing, then in your home directory temporarily rename:

• .zshrc
• .zlogin
• .zprofile
• .zshenv

You may or may not have some or all of those scripts present.

Then try launching Terminal.app again.

If that resolves the error, debugging the contents of your login scripts is next.

garage4996 wrote:

… [please use code <> tags for code] …

% /Users/star/ bw create attachment --file/document/encrypted.asc --itemid abg4d9a3-7490-4112-9b99-ac67014bbcbd 
zsh: permission denied: /Users/star/
% 

That command has a space where it does not belong. Specifically, within the file path to the app.

I’d expect the following to work better, or to at least not get bash or zsh cranky, with the space removed:

% /Users/star/bw create attachment --file/document/encrypted.asc --itemid abg4d9a3-7490-4112-9b99-ac67014bbcbd 
% 

or slightly more succinctly, using the tilde notation for the home directory:

% ~/bw create attachment --file/document/encrypted.asc --itemid abg4d9a3-7490-4112-9b99-ac67014bbcbd 
% 

macOS Mail includes S/MIME, as well as some other options, if you want to encrypt files for transfer.

garage4996 wrote:

star@stars-iMac ~ % ~/bw get item Documents/recovery_codes.txt

? Master password: [hidden]

Not found.

star@stars-iMac ~ % 

Ah ,now I understand the meaning of </> tags . by typing bw get item here I try to get the id number of the file recovery_codes.txt I searched with the command ls **/ and it showed that this file is in the documents and it is in the documents . Still the ID number is not found. The information I get from You and Ruggiero are wery useful . Now I will try to get the ID number of this file -but really I do not know how.

A path specification that is not position-relative:

~/bw get item ~/Documents/recovery_codes.txt

If this is something about the syntax or usage or operation of the command itself (and as appears to be the case here), check with Bitwarden support.

https://bitwarden.com/help/cli/

There’s somewhat of a command description there, and there’s also a support link. Based on a quick look at that documentation, the get item command requires an id parameter, which is not specified here, or is mis-specified as a filename. Unless you have an item (not file) identifier of Documents/recovery_codes.txt stored, you probably should get the Not Found error, too.

You’re now into the details of the Bitwarden bw command and its operations. I don’t have that available. Check with the app vendor.

Maybe the following explanation can help a bit:

The Terminal command line requires you to type, there is no mousing around. The command processor in Terminal, be it bash or zsh or any other one, needs to make sense of what you type. For this your command line is split into parts (called tokens). The split happens at whitespace (blanks, space characters usually).

Let's look at how bash sees your command line. I copy the one from above. For clarification I enclose each identified token in [ ] (these are NOT part of the syntax, they're just there to show you how bash sees the command)

[~/bw] [create] [attachment] [--] [file] [~/documents/mailfence] [recovery_codes.txt] [--] [itemid] [6e716541-a5cb-35ff-ab17-bc700041e3b1]

The very first part on each command line (here it is ~/bw) is the command itself, all other tokens are options and parameters that the command uses to work with. Any option's name is usually preceded by one or two dashes (in your case two). These are part of the option's name and MUST NOT be separated from it. Your command line has a space char between -- and the name which breaks the command. One such example is -- file instead of --file. On the other hand some space chars split the command line into tokens where it should not happen. [~/documents/mailfence] [recovery_codes.txt] should actually be ONE token. To prevent the command processor from seeing the space character in the file name you should enclose the complete file name in double quotes. This hides the space character and it will not act as the split character.

Your command line should now be like this:

~/bw create attachment --file "~/documents/mailfence recovery_codes.txt" --itemid 6e716541-a5cb-35ff-ab17-bc700041e3b1

You ask about code, what code? What you type into the Terminal is some form of code. It is actually one line of the bash (or zsh) programming language. As all characters and whitespace is relevant in any form of programming such code should be formatted in a way that one can clearly see all spaces etc. Normal text is written with letters of varying width making it often hard to see whether there is a space character or not. The </> icon applies a format that is better suited for code. If you look at the row of icons at the bottom of this editor window there is this </> one icon. Easiest is to type the (code)text (or copy/paste it from Terminal), select that text and then click this </> icon.

Hope this makes things clearer.

garage4996 wrote:

The ~ is a wery good idea too and I will try it with that . Then when I did not used the space / bw and just /bw then I got this message : commend not found . I will use the tilde and see if that works without putting an empty space - maybe that works.

The space is likely an error in this context. You’ll either need to quote the space if that is needed (as paths can contain spaces, but those mean using the appropriate shell syntax), or omit the space if it is not needed. Spaces are significant to the shell, and can also exist in paths and names. Care is needed when mixing the two.

The tilde is the path to user’s home, login directory.

If that home directory is /Users/shortname, then ~/toolname is the same as /Users/shortname/toolname in most contexts.

The tool you are referencing would have to be located there.

The following directory-listing commands are related, too:

ls ~/toolname
ls /Users/shortname/toolname

Above assumes the user’s particular login directory name is shortname

If the tool is not installed, or is installed elsewhere, you would need the path to that location.

Homebrew, if you’re using that, puts its stuff either somewhere under /usr/local or somewhere under /opt/homebrew, depending on the context and the tool.

garage4996 wrote:

star@stars-iMac ~ % ~/bw create attachment -- file ~/documents/mailfence recovery_codes.txt -- itemid 6e716541-a5cb-35ff-ab17-bc700041e3b1 

You really need to use </> tags when posting code here.

There are several issues with the command shown.

Twice added a space where it does not belong, and the path is incorrect, and the wrong case was used on the path.

The lattermost issue is (here) harmless, but using the wrong case in other places within the shell can be bad. Adding spaces can be catastrophic in some commands and places, too.

% ~/bw create attachment --file ~/Documents/mailfence/recovery_codes.txt --itemid 6e716541-a5cb-35ff-ab17-bc700041e3b1 

garage4996 wrote:

</> this is not clear at all what this means ?? Posting code here ?? What code ? You mean the itemid? That is an id and not a code and it is not real .

Do you see differences in how the shell commands I post in my replies look, and how the commands you post here look?

Here is an example of using the </> code-insertion tool:

Why this code-insertion request? The forum code insertion tool shuts off certain types of text formatting. Types of text formatting that can be problematic for shell commands, formsource code, and other such. Examples of issues include combining two hyphens into an em dash. An em dash looks nice, but the shell won’t like it. Another example is quoting. The shell wants vertical quotes, and the forum text formatting will switch to angled quotes, and the shell won’t like that either. And wrapping. The code insertion tool only wraps when you insert that, and not automatically for display width. The shell can get tangled with unexpected whitespace, as has been discussed above.

The shell is (for better or worse) all about these sorts of details.

As I looked up ls -l I have no permission to change anything on the macintos disc so I need to change this too - as I think .

Absent shutting off macOS system integrity protection, you won’t be able to write anything there. macOS protects itself against modifications, both for easier migrations, and to make persisting malware more difficult. The root directoires are among the protected areas. Stay in the /Users area, or in a few other specific directory paths. As you’re still learning more about the shell and about macOS itself, it’s probably best to stay in your own /Users/yourshortname directory and subdirectories for now.

PS: above reply from ruggiero is an excellent description of what you are encountering.

If your PATH is improperly set in your ~/.zshrc, or you are attempting to access a command in that file that cannot be found because of a PATH issue, you may get permission or file not found errors. There may be other reasons.

Okay, so the command worked. Your syntax for whatever this bw (presumably Bitwarden) command is, well, wrong.

The error here is likely again a space, this time a missing space after the switch and before the associated parameter.

Using the </> tag here in the forum to make the command syntax clear, the following command is probably closer to what is required for this bw command, and this example also uses a second tilde in the parameter:

% ~/bw create attachment --file ~/Documents/encrypted.asc --itemid 1e787638-a5cb-59ff-ab17-ac600041e3b5

I’ve also upper-cased the Documents path to match what macOS uses. unlike some other Unix and Linux systems, macOS is usually case-blind for paths, but shell commands and switches are case-sensitive. It’s best to preserve case everywhere.

For command syntax, there is a help switch, and also see the following documentation: https://bitwarden.com/help/cli/

As for your “normalcy” question, the command shell is (so far) working entirely as documented and intended.

I don’t have a good intro pointer for zsh available (somebody else might), and way too many of the zsh intros I do find around the ‘net spend a fair amount of time just installing zsh (a task which isn’t necessary or even appropriate here), though the following zsh intro might suffice:

… https://zsh.sourceforge.io/Guide/zshguide.pdf

garage4996 wrote:

This maybe not so easy as I newer did this before and I do not understand the process

You’re seeking to use the command line. Errant commands can cause data loss.

If you want to learn more the command line, consider creating a second non-admin login, and switching to that and experimenting there. In a second and non-admin login, any command issues or errors are contained to that login, and unlikely to effect your own data in your main login, or other users, or the macOS system itself.