In this explanation I will not explain what the special folder names of "." and ".." stand for, I have already explained that elsewhere. For short: "." is an alias for the current directory, ".." is one for the next folder below in the folder hierarchy. E.g. when you are in a folder named /tmp/test then "." would be a reference to /tmp/test itself, and ".." would be a reference to "/tmp"
______________________________________________________
Ed_P wrote: ↑01 Dec 2020, 20:49
a. You were talking about the unique regex "." and how it is used to delete files.
No, I brought now two examples explaining that
in usual every day bash or sh use the "." is read literally. Not as regex, or in other words:
the exact opposite of what you presumed above.
My first example illustrating the literal use of "." not the regex one:
When using *.exe to address filenames for bash and sh that translate into
"*" "any character, also none character, but not the new line character[¹]"
"." "a literal '.' - not 'one character' "
"exe" "exe"
Let us presume the following alias for l and the following test files:
Code: Select all
root@porteus:/tmp/test# alias l
alias l='/bin/ls -oa --color=auto --time-style=long-iso'
root@porteus:/tmp/test# l
total 0
drwxr-xr-x 2 guest 160 2020-12-02 03:08 .
drwxrwxrwt 16 root 480 2020-12-01 19:58 ..
-rw-r--r-- 1 root 0 2020-12-02 03:08 .dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 d.exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 dummy.exe
-rw-r--r-- 1 root 0 2020-12-02 03:01 dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 exe
Now, let us test my hypothesis:
Code: Select all
root@porteus:/tmp/test# l *.exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 d.exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 dummy.exe
root@porteus:/tmp/test# l .*exe
-rw-r--r-- 1 root 0 2020-12-02 03:08 .dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
root@porteus:/tmp/test# l .exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
root@porteus:/tmp/test# l .* -d
drwxr-xr-x 2 guest 160 2020-12-02 03:08 .
drwxrwxrwt 16 root 480 2020-12-01 19:58 ..
-rw-r--r-- 1 root 0 2020-12-02 03:08 .dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
root@porteus:/tmp/test# l .?* -d
drwxrwxrwt 16 root 480 2020-12-01 19:58 ..
-rw-r--r-- 1 root 0 2020-12-02 03:08 .dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
root@porteus:/tmp/test# l .??* -d
-rw-r--r-- 1 root 0 2020-12-02 03:08 .dummy_exe
-rw-r--r-- 1 root 0 2020-12-02 03:00 .exe
I hope you now finally see what I mean.
I recommend all users to only use hidden files or folders that have at least two characters after the initial "." that marks the file (or folder) as hidden.
By adhering to that simple rule, you can exclude the special folder names of "." and ".." by using ".??*" to address your file and folders.
".?*" would always also find the special folder of ".." - as seen in the above example.
And by the above example we also covered the area of my previous post
second example: the one addressing hidden or dot-files: meaning any files or or folders - but also the special folders "." and ".." - that start with a "." - which by UNIX and Linux specifications is what marks these as hidden.
Of course you are free to create hidden files and folders that contain two characters that start with a "." but are not the special folder name of "." like ".a" or ".1" or ".;", but like I wrote above, that would hinder you in using a mere ".??*" to address these files and folders while excluding the special folder ".."
Of course there are ways in using e.g. ".a" as file name or folder name and still address all such files or folders while excluding the special folder ".." by using regex, but that is not what this very post and my last two posts are about, so I omit it for now.
Again, with addressing the hidden file issue, bash and sh read a file or folder name starting with a "." not as "one character", but as a literal ".", always.
______________________________________________________
Ed_P wrote: ↑01 Dec 2020, 20:49
b. I was also impressed with your ls .* * -d command and when I tried it I forgot the -d and was amazed at what it produced on my system.
Because of the special folders ".." and "."
______________________________________________________
Ed_P wrote: ↑01 Dec 2020, 20:49
c. Forums, including this one, are for discussions where people exchange ideas and help others solve problems.
d. This is not your forum, you post something, you will receive responses that you may, or may not, agree with.
I think you misunderstood of what I meant by what I wrote, and you not even quoted what you are referring to.
All I meant is that the thread is about me giving coding tricks and advice, so when I define a topic like the literal reading of "." not a regex one then what I gave as examples is to illustrate the point. If you want to discuss a different approach showing the regex use of "." you are free to do so, even in here.
But on the other hand, no one is forced to answer to anything she or he does not want to. That is what I meant: I started this thread, and while others can discuss anything in here that is on-topic, meaning
Ravas coding,
not just any coding (see how the thread is named very specifically, not named as a generic "let us discuss any coding topics" subject), they can do so. But I not have to answer when I do not want to, that was meant by me writing you should start your own thread.
And if someone would start discussing any coding stuff that derails the threads subject - "
Ravas coding goodies", I could delete such posts because they would be off-topic here. Again: be aware of the very special way the subject is named.
The correct thread for such would be a generic subject like "coding tips" or whatnot, and not "Ravas coding goodies".
I hope we finally cleared up all misunderstandings!
__________________
[¹] One or more newline characters can be a legitimate part of any UNIX / Linux file or folder name, but even more so than just a whitespace, newline characters break most scripts because the coder never anticipated that a file or folder name can be composited of more than one line.
Anyone who coded one-liners for sh or bash, or coded scripts for sh or bash encountered the issues with file or folder names containing whitespace(s), but that issue is easy to handle, compared to the can of worms if you want to make your script fit handling file or folder names containing newline character(s) or in other words: more than one line of text info as name.