?....???

[brookter1]

you’re awesome!

(That vid definitely had quite a lot of great info too, but for a noob with no previous knowledge quite a lot in a very short time to (fully) comprehend) 👍

I think the advice you’ve been getting in this thread has been full of very clever tips which are very useful in certain circumstances. But I do wonder if it’s too complicated for a beginner, risking confusing you.

Personally, I’d consider an alternative approach, based on the following ground rules.

1) Only work on files you’re prepared to lose! I’d copy a few files in Finder to a new folder to play around with. Then right click on the folder and in the Services menu, open a Terminal window which will be based inside that folder.
2) Don‘t go anywhere near any folders outside your Home directory
3) Don’t bother with Man pages (yet): they are very useful, but they’re technical guides, not tutorials. Look on Google for simple tutorials instead.
4) Irrespective don’t go anywhere near commands which require super user access (e.g. sudo or switching your user to root).

Obviously, you’ll be able to move beyond these constraints fairly quickly, but in the meantime you’ll have a safe environment to experiment in.

As for the first things to explore, I’d learn how to do the following right at the start:

1) List the contents of a folder in short form (ls), longer form (ls -l), and longer form with hidden files (ls -la)
2) Create a folder (mkdir newfolder) and learn how to move into it (cd newfolder) Move back up one stage in the hierarchy (cd ..)
3) Rename a file (mv oldname newname)
4) Move a file into your new folder (mv file newfolder/)
5) Copy a file into your new folder (cp file newfolder/)
6) Copy a folder into your new folder (cp -a folder newfolder/)
7) Create a link to a text file in another folder – i.e. the same principle as aliases in Finder (though links are more powerful…) - (ln -s original newfolder/originalname or ln -s originalname newfolder/newname) NB the -s is important! Learn how to distinguish an alias from its original in the ls -l list.
8) Delete a file (rm file). This prompts you to be sure — don‘t override the prompt with rm -f until you’re more experienced as deleted files are gone for ever by default: i.e. they don’t go to Trash first
9) Get comfortable with the -h flag which most commands have to give you a short list of options (cp -h)
10) Learn how to read the contents of a text file without opening it (less).


It shouldn’t take long to get comfortable with these commands and then you can start branching outside the home directory, learning how to use sudo and other more sophisticated tools.

Of course, that list isn’t definitive and others will suggest different options. I apologise if some of this is too basic, but as you’ve emphasised several times that you’re a beginner to the CLI, I wonder if you’d be more comfortable with this sort of approach before you start on the more complicated features?

Anyway, please feel free to ignore if it’s too basic!

 

[unrigestered]

I think the advice you’ve been getting in this thread has been full of very clever tips which are very useful in certain circumstances. But I do wonder if it’s too complicated for a beginner, risking confusing you.

many of them certainly are. though most are extremely helpful even for me nevertheless.


haven't really tinkered too much with nano, touch, or echo yet, as the closest command to those on DOS was "edit", and the usage still feels a bit alien to me, unlike cd/mkdir/rm/ls, etc. (in it's basic way, disregarding it's options), mv, etc. which are similar enough to DOS, sometimes even pretty much identical workflow wise.
haven't heard of that "ln" command yet, so something else to look into at one point. 👍

I usually try to keep it simple and IMO usually only asked quite basic things to get me going at all so far though.
My last question might have ended up getting quite advanced answers that indeed go way beyond what i would / should use for now (which i am extremely grateful for nevertheless: it's a treasure trove for a time when/if i have learned UNIX well enough to get my hands dirty with them), but it simply didn't make any sense to me that i couldn't ls some directories, while i could view them in Finder.
This was answered, plus much more info that might prove extremely helpful when the time comes. 👍



oh, and while we're at it, i'd have another nagging question, that neither "man ls" nor "ls -h" solved for me (or i'm just too blind to see) :
is there a way to set ls to wait for a key command to continue, should the list of contents reach the bottom of the shell, so you don't have to scroll back up if the directory had dozens, or hundreds of files inside?
I might be wrong, as it has been a long time, but i think in DOS it used to be the "-p" appendix

 

[brookter1]

oh, and while we're at it, i'd have another nagging question, that neither "man ls" nor "ls -h" solved for me (or i'm just too blind to see) :
is there a way to set ls to wait for a key command to continue, should the list of contents reach the bottom of the shell, so you don't have to scroll back up if the directory had dozens, or hundreds of files inside?
I might be wrong, as it has been a long time, but i think in DOS it used to be the "-p" appendix

That's a feature I didn't mention: that you can chain commands together from small components using a pipe (|). This is actually pretty fundamental to Unix and the CLI.

Try these two commands in the terminal:

ls -l ~/Library
ls -l ~/Library | less

The first is too long to fit on the screen, the second pipes the output to the command 'less' I mentioned before, where it will show a screenful at a time. Press space to go to the next screenful, g to go back to the top and q to quit.

HTH.

 

[unrigestered]

ah yes, i heard about the pipes, and i think i read about less (and more), but as a (former) DOS user, it didn't occur to me that you could combine these to get such results 😂

(going to try right away!) 👍

 

[unrigestered]

it worked! 👍

i wonder though, as i am aliasing ls with -F and -G attached, as to why the output of "ls -F -G" is becoming monochromatic when piping with "less"?
The -F is still working, but -G is seemingly inactive.
no major issue, but any idea of the cause of such behavior?

 

[MisterSavage]

A nice use of aliases is to make "safer" versions of commands you use. For example, have an alias "cp" that is really "cp -i". The -i arg prompts you asking if you're sure that you want to overwrite an existing file.

 

[brookter1]

it worked! 👍

i wonder though, as i am aliasing ls with -F and -G attached, as to why the output of "ls -F -G" is becoming monochromatic when piping with "less"?
The -F is still working, but -G is seemingly inactive.
no major issue, but any idea of the cause of such behavior?

Don't know, I'm afraid! I've always just lived with it. There's probably a setting somewhere ;-)

 

[unrigestered]

A nice use of aliases is to make "safer" versions of commands you use. For example, have an alias "cp" that is really "cp -i". The -i arg prompts you asking if you're sure that you want to overwrite an existing file.

yup, while googling i've also seen some people alias .. for "cd .." ... for "cd ../..", etc.
i don't use these as i'm fast enough with just the usual cd.. and use it a couple of times using the up arrow to recall the last command(s), but i wonder what niceties one could come up with

(as a (former 😂 ) DOS user, i was inclined to alias md for mkdir at first 🥸

 

[brookter1]

yup, while googling i've also seen some people alias .. for "cd .." ... for "cd ../..", etc.
i don't use these as i'm fast enough with just the usual cd.. and use it a couple of times using the up arrow to recall the last command(s), but i wonder what niceties one could come up with

(as a (former 😂 ) DOS user, i was inclined to alias md for mkdir at first 🥸

You may want to have a look at OhMyZsh (https://ohmyz.sh), which essentially tarts the normal zsh terminal up a bit…

It has a lot of really useful features built in (e.g. more developed autocomplete) and it has a lot of aliases included, such as the cd ../.. one you mention. E.g. d lists the last few directories you visited and you can just press a number to go to relevant one.

But be warned, OhMyZsh has a huge range of plugins and it's easy to get lost in them…

 

[unrigestered]

yup,i like to keep it simple and usually try to stay away from too many add ons or apps that are not absolutely vital to my workflow.

 

[MisterSavage]

It has a lot of really useful features built in (e.g. more developed autocomplete) and it has a lot of aliases included, such as the cd ../.. one you mention. E.g. d lists the last few directories you visited and you can just press a number to go to relevant one.

Wow! That one is great. I've been using z for a similar purpose but this is another nice choice to have.

 

[mfram]

i wonder though, as i am aliasing ls with -F and -G attached, as to why the output of "ls -F -G" is becoming monochromatic when piping with "less"?
The -F is still working, but -G is seemingly inactive.
no major issue, but any idea of the cause of such behavior?

The color shuts off when going through a pipe because of how color text is generated on a Unix terminal. Special "escape codes" are used to change the behavior on a Unix terminal including generating color. And those escape codes likely won't work properly though a pipe which isn't a terminal. The programming library, called "ncurses", which generates those codes (and generally deals with terminal behavior) knows about that and knows when the output of a program is going though something other than a terminal.

If you'd like to see what happens anyway, use 'ls -F -G --color=always | less' and you'll see the results.

 

[bogdanw]

3) Don’t bother with Man pages (yet): they are very useful, but they’re technical guides, not tutorials. Look on Google for simple tutorials instead.

I disagree in principle and prove myself wrong at the same time.
Man pages should be the first source consulted, as they should provide the available options for the system.
Different macOS versions have different options for commands. Some have been depreciated in newer version, other have been introduced. Google or other search engines return the most popular results, that might not work for a current macOS version.

Unfortunately, some of Apple’s man pages are a mess.
Example: in Big Sur, man softwareupdate does not include any mention of the options --list-full-installers and --fetch-full-installer, but they they are described in help softwareupdate -h

 

[brookter1]

I disagree in principle and prove myself wrong at the same time.
Man pages should be the first source consulted, as they should provide the available options for the system.
Different macOS versions have different options for commands. Some have been depreciated in newer version, other have been introduced. Google or other search engines return the most popular results, that might not work for a current macOS version.

Unfortunately, some of Apple’s man pages are a mess.
Example: in Big Sur, man softwareupdate does not include any mention of the options --list-full-installers and --fetch-full-installer, but they they are described in help softwareupdate -h

No, really, no! (Not about Apple's Man pages, though 😀)

When you want to know the details of a how a command works, great. But for a beginner, trying to feel their way round the system, they can be utterly confusing. They're not tutorials, so it's a mistake to treat them as though they are.

Of course you need to know how and when to use them, but that time isn't in the initial period of getting comfortable with the CLI.

For example, type in `man cd`. You get the man page for Builtin, which tells you to look at the man pager for your shell to see individual commands. Ok, so you type in 'man zsh' which tells you that they've split the man pages in to several sub pages. So you work out that you need 'man zshbuiltins' and finally, after searching for cd or paging down a lot you get:

       cd [ -qsLP ] [ arg ]
       cd [ -qsLP ] old new
       cd [ -qsLP ] {+|-}n
              Change the current directory.  In the first form, change the current directory
              to arg, or to the value of $HOME if arg is not specified.  If arg is `-',
              change to the previous directory.

              Otherwise, if arg begins with a slash, attempt to change to the directory given
              by arg.

              If arg does not begin with a slash, the behaviour depends on whether the
              current directory `.' occurs in the list of directories contained in the shell
              parameter cdpath.  If it does not, first attempt to change to the directory arg
              under the current directory, and if that fails but cdpath is set and contains
              at least one element attempt to change to the directory arg under each
              component of cdpath in turn until successful.  If `.' occurs in cdpath, then
              cdpath is searched strictly in order so that `.' is only tried at the [several more paragraphs]

All useful stuff, but not yet for a beginner.

 

[unrigestered]

my first thoughts about "man" (after i successfully made it work when i put it in front of a command instead of after 😂):

"a lot of text for (almost) no explanation"

i'm using it, especially with bogdanw's piped to PDF command, but it is still often somehow still manages (not always though!) to be more confusing than helpful.
In fact, -h, or in some cases --help often do a better job for me to get a grasp.
but mostly googling, or this thread here in particular are the real help as i surely would still have been stuck right at the very beginning (not that i'd call me much more adanced than that though), other than the very basics that easily translate from my DOS days.

 

[MisterSavage]

my first thoughts about "man" (after i successfully made it work when i put it in front of a command instead of after 😂):


i'm using it, especially with bogdanw's piped to PDF command, but it is still often somehow still manages (not always though!) to be more confusing than helpful.
In fact, -h, or in some cases --help often do a better job for me to get a grasp.
but mostly googling, or this thread here in particular are the real help as i surely would still have been stuck right at the very beginning (not that i'd call me much more adanced than that though), other than the very basics that easily translate from my DOS days.

For a tutorial man pages aren't great. If you want to see what an argument does or what a return value is they're helpful.

 

[unrigestered]

yes, i've just tried a few more and i seem to get along with it better now.
maybe i was "man-ing" the wrong commands before, or maybe i just (re)gained some IQ back somehow 😂

 

[sgtaylor5]

Sometning no one has mentioned yet, and that is "Capitalization Matters" when you're working in the Terminal, in Unix, Linux or macOS.

a command switch "-r" is going to have different functions than "-R"; also, "Documents" is a different folder than "documents".

 

[unrigestered]

yes, i noticed that rather quickly, when ls -r didn't work as expected (like ls -R does)

regarding capitals in folders: i actually haven't found much of a difference yet, as i have no trouble changing or listing directories in lower case, regardless how they are spelled
also mkdir test after i created a Test folder does end in an error message that it already exists

so where do the differences lie?

 

[sgtaylor5]

yes, i noticed that rather quickly, when ls -r didn't work as expected (like ls -R does)

regarding capitals in folders: i actually haven't found much of a difference yet, as i have no trouble changing or listing directories in lower case, regardless how they are spelled
also mkdir test after i created a Test folder does end in an error message that it already exists

so where do the differences lie?

well, maybe capitals in folders don't matter. I just tried to do an ls -la for the "documents" folder and it came right up.

 

[NoBoMac]

By default, APFS MacintoshHD is formatted as insensitive. HFS+ was/is insensitive as well (probably, as guessing APFS is insensitive for compatibility reasons)?

But, yeah, case sensitivity can be a thing.

 

[MisterSavage]

By default, APFS MacintoshHD is formatted as insensitive. HFS+ was/is insensitive as well (probably, as guessing APFS is insensitive for compatibility reasons)?

But, yeah, case sensitivity can be a thing.

How cow, I never realized this! I use filename completion so much I've apparently never tried (or never noticed) that different case would work.

 

[NoBoMac]

How cow, I never realized this! I use filename completion so much I've apparently never tried (or never noticed) that different case would work.

I've probably done it by accident in the past, but the old *nix-er in me is a stickler for using proper case.

But in some cases, case does matter. For example, this simple find example:

% find . -type d -depth 1 -name 'documents'
find: ./Library/Logs/DiagnosticReports/Retired: Permission denied
% find . -type d -depth 1 -name 'Documents'
find: ./Library/Logs/DiagnosticReports/Retired: Permission denied
./Documents
%

 

[MisterSavage]

This thread is pure gold. Been using shells for ages but have already learned some great things!

 

[bogdanw]

I made a bootable installer today (https://support.apple.com/HT201372) and I remembered of a simple way to get a confirmation when executing a command that takes a long time: use say ‘something’ after.
Example using the command above

find . -type d -depth 1 -name 'Documents'; say 'command executed'