Re: !(.pattern) can match . and .. if dotglob is enabled
Hello, > Personally, I'd just want an option to always make . and .. hidden from > globs. [...] If such option existed, I would certainly use it. As I already said, I can't imagine why anyone would ever want a pattern to match `.' or `..' (unless the entire path component is literal). But even if I had such option, I would still want the default behavior to be easy to understand and fully documented, therefore I maintain my proposed changes. __ About dotglob, this is subjective but personally I would never prefer to have it unset. It happened to me quite a few times that I forgot to include dot files by accident, but never the other way around (even after ten years of dotglob set). When it is not a very conscious choice and I just think "I want all files", usually all means all. When I don't want dot files (rarely), I'm usually very aware of it and I just use `[^.]*'. And even more importantly, dotglob allows me to exclude `.' and `..' by protecting the leading dot with brackets. From your example: $ touch .dot normal $ echo [.]* .dot $ echo ./[.]* ./.dot > For what it's worth, Zsh, mksh and fish seem to always hide . and .. Just for curiosity, is that still standard compliant? (I'm talking about non-extended patterns, like `.*') > I tried to achieve that via GLOBIGNORE=.:.. , but that has the problem that > it forces dotglob on, and looks at the whole resulting path, so ./.* still > gives ./. and ./.. . Unless you use GLOBIGNORE=.:..:*/.:*/.. etc., but > repeating the same for all different path lengths gets a bit awkward. Yes, I also tried GLOBIGNORE a long time ago, and it won't cut the salami. I think GLOBIGNORE=.:.. is error prone because you get used to it and then you get bitten when there is more than one path component. If you want to cover all cases, there's no need to take into account all different path lengths because `/' is not special. You just have to cover 4 cases (alone, at start, in the middle, at end): GLOBIGNORE=.:..:./*:../*:*/./*:*/../*:*/.:*/.. But the effect is still not useful (e.g. `./*.txt' will fail to match `./foo.txt'). While I'm at it, I will also point out that the docs suggest adding `.*' to GLOBIGNORE if the automatic activation of dotglob is undesirable. I think such suggestion is misleading because the effect is very different (e.g. with dotglob unset `.bash*' still matches `.bashrc' etc. but with GLOBIGNORE=.* it won't). Regards, NP
Re: Prefer non-gender specific pronouns
On Sun, Jun 06, 2021 at 05:00:21PM +0300, Ilkka Virta wrote: > On Sun, Jun 6, 2021 at 2:49 PM Léa Gris wrote: > > For the second person, there's of course "thou", but for some reason, > I've never heard anyone suggest using that in practice. Hast thou never been to Yorkshire or Lancashire? :-) One can still occasionally experience thee/thy/thou/thine in all their glory. Some of us could cope with 'thou art' rather than 'you are', but it does tend to feel a bit archaic. DF
Re: [PATCH] Prefer non-gender specific pronouns
On Sun, Jun 6, 2021, at 12:35 AM, G. Branden Robinson wrote: > At 2021-06-05T23:29:58-0400, Lawrence Velázquez wrote: > > doc/oldbash.texi > > 178:manual. Brian and Diane would like to thank Chet Ramey for his > > 9138:# The alternative explanation is that his frequent use of the > > My "git grep" didn't turn this file up anyway. Maybe I'm on the wrong > branch? I'm on the "devel" branch. > > That's three. Pretty tractable for anyone so inclined. (Didn't > > look at source code comments or anything.) > > Thanks, Lawrence! Sorry, you might want to redo your patch. It just occurred to me that I made a predictable oversight. % git grep --perl-regexp '\b(she|her|hers)\b' -- '*.texi' doc/oldbash.texi:# If the user has her own init file, then use that one, else use doc/oldbash.texi:and the second draft. Without her help, this manual would probably lib/readline/doc/rltech.texi:possible-completions call. After that, readline asks the user if she is sure lib/readline/doc/rltech.texi:she wants to see them all. The default value is 100. A negative value (I believe doc/oldbash.texi is a legacy document that needn't be bothered with.) -- vq
Re: Prefer non-gender specific pronouns
Le 06/06/2021 à 16:34, Oğuz écrivait : Then there is no need to change anything. Exactly. As a woman, I take no offense when a documentation illustrate a fictive male character. (and as I will illustrate below, in French pronouns are tuned in gender and number with the object). I am not offended by the wording of the current English Bash documentation either. I am more annoyed by the over-abundance of children's stories in which women are depicted as 1950's good, dedicated and submissive housewives, cooking diner and taking care of kids. But seriously, in the few Bash manual sentences giving a male gender to the illustrative user character. This is light-years away of a worthy concern to me. I even predict this would get fixed with consensus if when more women will be involved in IT. Interestingly for the story: In the 1960's and 1970's, when we were more widely seen as housewives, we were more represented in IT, science and engineering overall than of today, that gender equity and equality are accepted modern standards. And no, I can't believe rewriting Bash documentation with gender neutral is a good thing or that it can contribute to evening the balance of gender representation in IT either. What word(s) are used in translations of the manual into languages other than English ? Do similar problems exist. In mine, no. Turkish has only one pronoun for male, female, and inanimate. In mine, possessive pronouns are gendered to the possessed target. Example with current Bash documentation place that have been subject to these gender-neutral changes, translated to French: > in a non-writable directory other than his home directory after login, dans un répertoire autre que son répertoire HOME après connexion, ^^^ French "son" (his) is male because "répertoire" (directory) is male in French. User character's gender is not even mentioned. -- Léa Gris
Re: Prefer non-gender specific pronouns
On Sun, Jun 06, 2021 at 05:12:21PM +0300, Oğuz wrote: > If that really is a problem that has to be addressed and not > bike-shedding, let's compromise and say "his/her" instead of "his" or > "their". *sigh* I probably shouldn't do this, but let's dive into this just a bit, because apparently it's too late to turn back now. As background information, I was born in 1970 and was educated in the public school system in the United States. I supply this background information because how one responds to this discussion depends greatly on WHEN and WHERE one learned English grammar. That's why there is such incredible divisiveness on this topic. In the grammar classes that I took in school, we were taught that "they" and "their" are plural pronouns, and should always be used as such. I believe at least one other person on this list was taught a similar thing, and has not updated his or her standards. We all know the person to whom I'm referring. It's the really loud, angry one. Now, I'm not an expert on the entire history of English grammar education around the world, but it's my understanding that this ironclad insistence on the plural-ness of "they" was prevalent mostly in the United States, in the mid to late 20th century. Thus, it was how many of us were raised, but not all of us. The issue, just for the record, is the lack of an acceptable gender-neutral singular pronoun set in the current English language. There are a few choices, all of them bad: 1) "It". This is considered offensive, because it implies a lesser status (an inanimate object rather than a person). 2) "Him or her". This is awkward and long, and nobody likes it. 3) "Sie" and other non-English words. These were suggested in the 1990s but never caught on. 4) "They". Some people strongly dislike this because it conflicts with the grammar rules they were taught. 5) "Him". One of the older style guidelines suggested that when a person's gender is unknown, one should default to the masculine pronoun set, and the reader will understand that this is being used as a placeholder. So, English gives us 5 choices, and they all suck. Bash's documentation is using choice number 5, which was (as I understand it) commonly taught prior to the mid 20th century. It's basically 19th century usage, and reflects and reinforces the patriarchal societies of that time period. It's quite understandable that someone would dislike this choice strongly enough to offer a patch to undo it. Out of these 5 choices, the one that seems to suck the *least*, according to observed usage patterns in current written and spoken English, is "they". Personally, I've been trying to update my usage to embrace "they". It's not easy, and sometimes I forget and fall back into older patterns, but at least I'm trying. This is the way the language is evolving. If you refuses to embrace it, you will be left behind. (Unless of course a massive popular usage shift occurs and some other choice becomes the new front-runner. I've seen no signs of this happening.)
Re: !(.pattern) can match . and .. if dotglob is enabled
In my previous message, I wrote: > Yes, it all depends on the "universal set" from which the matches of the inner > `pattern-list' are subtracted. > But in the current implementation, the inner matches are subtracted from: > - all files, if dotglob is set > - all except dot files, if dotglob is unset Sorry, I got mixed up here. From the above it would look like `.' and `..' are never excluded from the matches of `!()' if dotglob is set. Actually they are normally excluded (which is fine), but they are included back again if at least one of the inner patterns starts with a literal dot. From this sentence: > !(pattern-list) >Matches anything except one of the given patterns. currently the definition of "anything" is affected not only by the value of dotglob but also by the content of `pattern-list'. I'm proposing that "anything" should be `*' (i.e. affected by dotglob but not by `pattern-list'). The usual dot treatment is applied to the inner patterns themselves but it doesn't make a difference in the final match. E.g. the two patterns `!(.?)' and `!([.]?)' should have the same effect: `.?' matches `..' `[.]?' doesn't match `..' but `*' minus `.?' is still equal to `*' minus `[.]?', because `*' matches neither `.' nor `..' (and the final result should never include them). My description of the desired behavior should still be sufficient.
Re: Prefer non-gender specific pronouns
6 Haziran 2021 Pazar tarihinde Alain D D Williams yazdı: > On Sun, Jun 06, 2021 at 05:12:21PM +0300, Oğuz wrote: > > > If that really is a problem that has to be addressed and not > > bike-shedding, let's compromise and say "his/her" instead of "his" or > > "their". > > Possible, but it detracts from the clarity of the sentence that it is in. So does "their". > > > Though I don't think women who read the manual and burst into tears out > of > > oppression when they see "his" actually exist. > > The important thing is that there is no intention to oppress/denigrate/... > women by the use of 'his'. Then there is no need to change anything. > What word(s) are used in translations of the manual into languages other > than > English ? Do similar problems exist. In mine, no. Turkish has only one pronoun for male, female, and inanimate. > > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 https://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > https://www.phcomp.co.uk/Contact.html > #include > > -- Oğuz
Re: Prefer non-gender specific pronouns
On Sun, Jun 06, 2021 at 05:12:21PM +0300, Oğuz wrote: > If that really is a problem that has to be addressed and not > bike-shedding, let's compromise and say "his/her" instead of "his" or > "their". Possible, but it detracts from the clarity of the sentence that it is in. > Though I don't think women who read the manual and burst into tears out of > oppression when they see "his" actually exist. The important thing is that there is no intention to oppress/denigrate/... women by the use of 'his'. What word(s) are used in translations of the manual into languages other than English ? Do similar problems exist. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Prefer non-gender specific pronouns
6 Haziran 2021 Pazar tarihinde Ilkka Virta yazdı: > > I do wonder, though, what the gender-neutral delusion here would be? That > there exist women > who use computers and Unix-like systems, and not just men? Even I know, in > real life, some > female Linux users, and while I haven't asked about shells, I expect they > might use Bash at > least to some extent. So I don't think it's unrealistic to accept the fact > that not all users of Bash > might be "he". That may of course have been different 30 years ago, but > then, the times do > change. > If that really is a problem that has to be addressed and not bike-shedding, let's compromise and say "his/her" instead of "his" or "their". Though I don't think women who read the manual and burst into tears out of oppression when they see "his" actually exist. -- Oğuz
Re: Prefer non-gender specific pronouns
On Sun, Jun 6, 2021 at 2:49 PM Léa Gris wrote: > Either you're acting in bad faith, or you're so confused by your > gender-neutral delusion that you don't remember that in normal people's > grammar, "they" is a plural pronoun. > Argh, no, that's just an example of the fact that I can't read. Sorry. I do agree, it would be useful if English did have separate singular pronouns, both for "you" and "they". But since it doesn't, we have to work with what we have. For the second person, there's of course "thou", but for some reason, I've never heard anyone suggest using that in practice. I do wonder, though, what the gender-neutral delusion here would be? That there exist women who use computers and Unix-like systems, and not just men? Even I know, in real life, some female Linux users, and while I haven't asked about shells, I expect they might use Bash at least to some extent. So I don't think it's unrealistic to accept the fact that not all users of Bash might be "he". That may of course have been different 30 years ago, but then, the times do change.
Re: Prefer non-gender specific pronouns
Léa, I see that in the section Ilkka quoted you were using it in the
plural. However Ilkka is exactly right; despite "they" being technically
plural, using it for somebody of undetermined gender has been in the
mainstream since long before inclusive language. "Someone left *their*
book, there's no name and I don't know who to call."
The AP and Chicago style guides, hardly reckless proponents of any
progressive vanguard, endorse this usage, though they recommend working
around it if possible ("Somebody left *a* book"). However they do
unequivocally endorse using it for somebody who declares "they" to be their
pronoun (though for now that may not have much bearing on the manual).
On Sun, Jun 6, 2021, 07:49 Léa Gris wrote:
> Le 06/06/2021 à 11:33, Ilkka Virta écrivait :
> > In fact, that generic 'they' is so common and accepted, that you just
> used
> > it yourself
> > in the part I quoted above.
>
> Either you're acting in bad faith, or you're so confused by your
> gender-neutral delusion that you don't remember that in normal people's
> grammar, "they" is a plural pronoun.
>
> --
> Léa Gris
>
>
>
Re: [PATCH] Prefer non-gender specific pronouns
Le 06/06/2021 à 06:35, G. Branden Robinson écrivait : Here you go, if you're inclined. Minimally invasive and decidedly non-revolutionary in terms on English lexicon. Your careful patch not using custom grammar is admirable. Although I remain alarmed because this is a work to obey a demand from cancel culture tenants. With all your clever carefulness in patching this. It remains a rewrite of history motivated by political reasons from a lobbying group of people spreading their damaging delusions everywhere. -- Léa Gris
Re: Prefer non-gender specific pronouns
Le 06/06/2021 à 11:33, Ilkka Virta écrivait : In fact, that generic 'they' is so common and accepted, that you just used it yourself in the part I quoted above. Either you're acting in bad faith, or you're so confused by your gender-neutral delusion that you don't remember that in normal people's grammar, "they" is a plural pronoun. -- Léa Gris
Re: !(.pattern) can match . and .. if dotglob is enabled
On Sun, Jun 6, 2021 at 1:31 PM Ilkka Virta wrote: > Personally, I'd just want an option to always make . and .. hidden from > globs. Or rather, > to never generate . or .. as a pathname component via globbing. But > without affecting > other behaviour, like dotglob, and without precluding the use of . or .. > as static parts of the > path. > Hmm, looking at the code, this already seems to exist, in lib/glob/glob.c: /* Global variable controlling whether globbing ever returns . or .. regardless of the pattern. If set to 1, no glob pattern will ever match `.' or `..'. Disabled by default. */ int glob_always_skip_dot_and_dotdot = 1; I didn't read all the code, but as far as I tested from the git version, that seems to do what I just wanted and seems sensible to me with Nora's examples too. (I changed the filenames from the previous since I started copying their tests now.) $ touch .foo .doo bar quux With dotglob (the first is the same as just *): $ shopt -s dotglob $ echo @(.foo|*) bar .doo .foo quux $ echo !(.foo) bar .doo quux $ echo @(bar|.*) bar .doo .foo Without it: $ shopt -u dotglob $ echo @(.foo|*) bar .foo quux $ echo @(bar|.*) bar .doo .foo No match for . and .. even explicitly (with failglob here): $ echo @(.|..) bash: no match: @(.|..) All files with dotglob unset: $ echo @(.|)* bar .doo .foo quux Maybe I missed some more obscure case, though.
Re: !(.pattern) can match . and .. if dotglob is enabled
> Can you write a set of rules that encapsulates what you would like to see? > Or can the group? > I think it's a bit weird that !(.foo) can match . and .. when * doesn't. The other means roughly "anything here", and the other means "anything but .foo here", so having the latter match things the former doesn't is surprising. Personally, I'd just want an option to always make . and .. hidden from globs. Or rather, to never generate . or .. as a pathname component via globbing. But without affecting other behaviour, like dotglob, and without precluding the use of . or .. as static parts of the path. As in: $ touch .dot normal $ echo .* .dot $ echo ./.* ./.dot And depending on dotglob, echo * should give either .dot normal or just normal . So, somewhat similarly to how globbing hides pathname components starting with a dot when dotglob is unset, just with another option to hide . and .. in particular. Frankly, I don't care if that would also mean that ./@(.|..)/ would match nothing. I don't see much use for globbing . and .. in any situation, the dangers of accidentally climbing up one level in the tree by a stray .* are much worse. Someone else might disagree, of course, but if one really wants to include those two, brace expansion should work since the two names are always known to exist anyway. And of course if it's an option, one doesn't need to use it if they don't like it. For what it's worth, Zsh, mksh and fish seem to always hide . and .. , and at least Zsh does that even with (.|..) or @(.|..) . I tried to achieve that via GLOBIGNORE=.:.. , but that has the problem that it forces dotglob on, and looks at the whole resulting path, so ./.* still gives ./. and ./.. . Unless you use GLOBIGNORE=.:..:*/.:*/.. etc., but repeating the same for all different path lengths gets a bit awkward.
[PATCH] Prefer non-gender specific pronouns
Hi Chet,
Here you go, if you're inclined. Minimally invasive and decidedly
non-revolutionary in terms on English lexicon.
Patch attached.
At 2021-06-05T23:29:58-0400, Lawrence Velázquez wrote:
> doc/oldbash.texi
> 178:manual. Brian and Diane would like to thank Chet Ramey for his
> 9138:# The alternative explanation is that his frequent use of the
My "git grep" didn't turn this file up anyway. Maybe I'm on the wrong
branch?
> That's three. Pretty tractable for anyone so inclined. (Didn't
> look at source code comments or anything.)
Thanks, Lawrence!
Regards,
Branden
From 2f831676ea69b64c4a8a44be7a675253e78527ce Mon Sep 17 00:00:00 2001
From: "G. Branden Robinson"
Date: Sun, 6 Jun 2021 14:22:41 +1000
Subject: [PATCH] [docs]: Adopt gender-indifferent language.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Noted by Vipul Kumar and Lawrence Velázquez on the bug-bash list[1].
[1] https://lists.gnu.org/archive/html/bug-bash/2021-06/msg8.html
---
doc/bashref.texi | 2 +-
lib/readline/doc/rltech.texi | 2 +-
lib/readline/doc/rluser.texi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/bashref.texi b/doc/bashref.texi
index 9e23f586..7ba3c448 100644
--- a/doc/bashref.texi
+++ b/doc/bashref.texi
@@ -7671,7 +7671,7 @@ The restricted shell mode is only one component of a useful restricted
environment. It should be accompanied by setting @env{PATH} to a value
that allows execution of only a few verified commands (commands that
allow shell escapes are particularly vulnerable), leaving the user
-in a non-writable directory other than his home directory after login,
+in a non-writable directory other than @env{HOME} after login,
not allowing the restricted shell to execute shell scripts, and cleaning
the environment of variables that cause some commands to modify their
behavior (e.g., @env{VISUAL} or @env{PAGER}).
diff --git a/lib/readline/doc/rltech.texi b/lib/readline/doc/rltech.texi
index bbf57c23..c3567a61 100644
--- a/lib/readline/doc/rltech.texi
+++ b/lib/readline/doc/rltech.texi
@@ -1611,7 +1611,7 @@ main (int c, char **v)
Signals are asynchronous events sent to a process by the Unix kernel,
sometimes on behalf of another process. They are intended to indicate
-exceptional events, like a user pressing the interrupt key on his terminal,
+exceptional events, like a user pressing the interrupt key on the terminal,
or a network connection being broken. There is a class of signals that can
be sent to the process currently reading input from the keyboard. Since
Readline changes the terminal attributes when it is called, it needs to
diff --git a/lib/readline/doc/rluser.texi b/lib/readline/doc/rluser.texi
index 26b0ff07..62df6ceb 100644
--- a/lib/readline/doc/rluser.texi
+++ b/lib/readline/doc/rluser.texi
@@ -339,7 +339,7 @@ Although the Readline library comes with a set of Emacs-like
keybindings installed by default, it is possible to use a different set
of keybindings.
Any user can customize programs that use Readline by putting
-commands in an @dfn{inputrc} file, conventionally in his home directory.
+commands in an @dfn{inputrc} file, conventionally in @env{HOME}.
The name of this
@ifset BashFeatures
file is taken from the value of the shell variable @env{INPUTRC}. If
--
2.20.1
signature.asc
Description: PGP signature
Re: Prefer non-gender specific pronouns
On Sun, Jun 6, 2021 at 5:50 AM Léa Gris wrote: > Le 05/06/2021 à 18:47, John Passaro écrivait : > > I can see a couple reasons why it would be a good thing, and in the con > > column only "I personally don't have time to go through the manual and > make > > these changes". but I'd happily upvote a patch from somebody that does. > > I can see so many reasons why it would be a bad thing to let the cancel > culture adepts slip in here, rewriting bash documentations with their > custom grammar. > Using 'they' for a generic, indefinite person, like the user here, one who could be anyone, is totally normal use of the language, and not even a very new invention. It's not the same as calling a definite person of known gender 'they'. In fact, that generic 'they' is so common and accepted, that you just used it yourself in the part I quoted above.
