Ok, well I assumed you couldn't because the majority of people don't regularly read old texts. But if you do understand it you should be able to understand it's quite different from modern German because the German language evolved over time. English is an even weirder language because it's basically three or four different languages rolled into one which then got influenced by a lot of other European languages (including but not limited to the Romance and Latin languages). And in modern times even American English and British English are slightly different, not only in spelling (color vs. colour for example) but also in words and meaning (trainers vs. sneakers).Yes. I can read that. With more effort old saxon. I do not know if old low frankish.
I have the impression that the oldest traded big text, old german tatian, is the easiest to read. Of courseBut if you do understand it you should be able to understand it's quite different from modern German because the German language evolved over time.
I do not understand what you mean. Perhaps you did not understand the context?You can't be offended when you're wrong and confronted with the facts or it falls on you.
Well perhaps you didn't understand what I meant.Well, perhaps you understand now that you did not understand the context. But as you said your "strong
opinion", you did not know it. You learn, hence you are also not omniscient.
I still do not understand. I have absolute no problem of being confronted with the facts. It is absolutely noI meant that when you're wrong and bitch about being confronted with the facts it's you that looks the part.
I'm not the people you asked, but here are the two problems I experience.could you please clarify what is the problem with a filename/folder with a space at the end?
> touch a b "c d" # You have created three files: "a", "b", and "c d" stat -r * 16777221 91145641 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 a 16777221 91145642 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 b 16777221 91145643 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 c d # This works, because the shell expands * to three strings, and passes the three strings to the stat command. > for f in * > do > stat $f > done 16777221 91145641 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 a 16777221 91145642 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 b stat: c: stat: No such file or directory stat: d: stat: No such file or directory # This doesn't work, because the "*" in shell was expanded into three strings, but when the string "c d" was passed # to stat, the shell parsed it as "stat c d", which means: stat the files c and d. > for f in * > do > stat "$f" > done 16777221 91145641 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 a 16777221 91145642 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 b 16777221 91145643 0100644 1 568476 89939 0 0 1616905731 1616905731 1616905731 1616905731 4096 0 0 c d # Great, now it works.
ls. Since this topic is new to me, and the entire data set I have is already a mess, I do not want to make it worse.
All the saved styles I copy from USB stick to /local/share/fluxbox/styles/ as saved as US-ASCII.And I in addition avoid Non-Ascii. I never put consciously an hyphen at the beginning. If filenames
were restricted, I would not miss much.
env ls -q ./*[![:graph:]]*should work (env(1) is necessary to avoid shell aliases/functions). If you need to handle file names in a machine-parsable way, just use an expression containing wildcards like ./*.
set -fin your script, wildcards are unavailable anyway, and you'll need to find an alternative solution that works for you (e.g. temporarily enabling pathname expansion, saving the results of a wildcard expression to a bash array, and using that array as necessary).
cd binhas two different behaviors, depending on whether CDPATH is set or unset:
cd ./binlimits the potential for accessing the incorrect directory, though you may want to use
cd ./bin >/dev/nullto avoid unnecessary output when CDPATH is set. devel/hs-ShellCheck is useful for detecting many possible issues, but I'm pretty certain this isn't one of the things it catches; I don't think there are a lot of scripts that get tripped up by CDPATH because it doesn't seem to be used much. Depending on what you script does, you probably can also just
unset -v CDPATHas well. I guess that's yet another thing to include before you actually start writing a script
It's not a regular expression, it's a character class. Regular expressions can use character classes too, that's true. But a character class doesn't mean it's a regular expression.Does shell support real regular expressions?!
An asterisk (`*') matches any string of characters. A question mark (`?') matches any single character. A left bracket (`[') introduces a character class. The end of the character class is indicated by a `]'; if the `]' is missing then the `[' matches a `[' rather than introducing a character class. A character class matches any of the characters between the square brackets. A locale-dependent range of characters may be specified using a minus sign. A named class of characters (see wctype(3)) may be specified by surrounding the name with `[:' and `:]'. For example, `[[:alpha:]]' is a shell pattern that matches a single letter. The character class may be complemented by making an exclamation point (`!') the first character of the character class. A caret (`^') has the same effect but is non-standard.
Reaction score: 1,215
Tabkey). For example (zsh):
$ touch foo "foo " $ ls foo<Tab> foo foo\
<Tab>key repeatedly cycles between the “
foo” and “