Hi!
On Sun, Jul 16, 2023 at 03:46:10PM +0200, Alejandro Colomar wrote:
> On 2023-07-16 13:55, наб wrote:
> [...]
> > I read it but didn't really understand what you were saying, since
> > you're on record as a text‒text‒text liker.
> In this context, I'm not sure if to read that as that being just
> emphasis on me being a text liker, which is true-true-true, or if
> (more likely) "text" are placeholders for random text, and you claim
> that I'm on record liking no spaces between em dashes. If it's the
> latter, I believe I am not, and you might have been confused by some
> of those records? Could you point me to the records?
I think you've said it to me before but I can't strictly find the mail
(but I'd hopefully blame that on my mail searching).
> Maybe I had
> some brain-fart and defended that at some point, but I do not like
> that style personally.
Neither do I but I, as usual, consulted the corpus, and it said
$ git grep -F '\[em]' | grep -Fe '\[em] ' -e '\[em] ' -c
to around 160/16 vs -cv.
Thus, I did what the corpus says.
> Basically, it is something similar to why we should write punctuation
> outside of quotes, unless they belong to them, so if I quote someone
> who said "Hello world!", I include '!' in the quote, as it belongs to
> the quote, but the ',' belongs to my text.
This is known (unfairly-)derisively as "programmer punctuation".
> The reason that I like spaces in (only) one side of em dashes --and I
> also like closing em dashes even right before other punctuation-- is
> to make parsing the text less complex. I've seen cases where in a
> paragraph, several em-dash asides appear, and it's hard to understand
> what is the main text and what are the asides, especially when the
> closing em dash of one of them is omitted.
The corpus sayeth:
$ git grep -F '\[em]' | grep -e '\\\[em\] ' -e ' \\\[em\]' -e ':\\\[em\]' -e '\\\[em\]$' | grep -v @
man2/futex.2:.IR "futex word" \[em]whose
man2/get_mempolicy.2:.IR nodemask \[em]that
man2/ioctl_iflags.2:.IR "inode flags" \[em]attributes
man2/madvise.2:\[em]including tmpfs (see
man2/madvise.2:.BR tmpfs (2))\[em]
man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
man2/uname.2:\[em] this is the largest value likely to be encountered in the wild.
man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
man3type/stat.3type:.RI fields\[em] st_atime ,
man3type/stat.3type:.IR st_ctime \[em]typed
man4/intro.4:/dev/* \[em] device files
man4/st.4:.SS MTIOCTOP \[em] perform a tape operation
man4/st.4:.SS MTIOCGET \[em] get status
man4/st.4:.SS MTIOCPOS \[em] get tape position
man7/man.7:.\" .IP \[em] 3m
man7/man.7:.\" .IP \[em]
man7/man.7:.\" .IP \[em]
man7/man.7:.\" .IP \[em]
man7/path_resolution.7:the process \[em] or in the case of
man7/tcp.7:Use this option with care \[em] it makes TCP less tolerant to routing
man7/unicode.7:Information technology \[em] Universal Multiple-Octet Coded Character
man7/unicode.7:Set (UCS) \[em] Part 1: Architecture and Basic Multilingual Plane.
man7/x25.7:Message boundaries are preserved \[em] a
of which these use ‒s as interjective commas:
man2/futex.2:.IR "futex word" \[em]whose
man2/madvise.2:\[em]including tmpfs (see
man2/madvise.2:.BR tmpfs (2))\[em]
man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
(whoops allotion, should be allocation)
man3type/stat.3type:.RI fields\[em] st_atime ,
man3type/stat.3type:.IR st_ctime \[em]typed
of which these have spacing around the outside:
man2/madvise.2:\[em]including tmpfs (see
man2/madvise.2:.BR tmpfs (2))\[em]
man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
This is, I'm pretty sure, the first time I've encountered this style,
and it kinda looks like a formatting error to me.
v6 with
op —with permissions configured on pty allocation, as is the case on Linux— or an ioctl(2).
scissored below.
-- >8 --
FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open(2),
and grantpt(3) is a no-op (that checks whether the fd is a pty, except on
musl).
The illumos gate and NetBSD do a ioctl (and, indeed, illumos-gate commit
facf4a8d7b59fde89a8662b4f4c73a758e6c402c ("PSARC/2003/246 Filesystem
Driven Device Naming"), which kills pt_chmod, notes that it's been
"6464196 bfu should remove pt_chmod, obsoleted by /dev filesystem").
glibc 2.33 completely kills BSD PTY support on Linux
(Debian hasn't configured with them on any architecture since 2007:
https://bugs.debian.org/338404
and even earlier on some arches; they're really just trivia under
Linux ‒ this may be better served stuffed into HISTORY as an explainer
for the SIGCHLD thing, since regardless of the "version", the behaviour
is well-defined and consistent).
Cc: Jakub Wilk <jwilk@xxxxxxxxx>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx>
---
man3/grantpt.3 | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/man3/grantpt.3 b/man3/grantpt.3
index a19172a3e..3c753da03 100644
--- a/man3/grantpt.3
+++ b/man3/grantpt.3
@@ -84,17 +84,15 @@ .SH ATTRIBUTES
.ad
.sp 1
.SH VERSIONS
-Many systems implement this function via a set-user-ID helper binary
+Historical systems implemented this function via a set-user-ID helper binary
called "pt_chown".
-On Linux systems with a devpts filesystem (present since Linux 2.2),
-the kernel normally sets the correct ownership and permissions
-for the pseudoterminal slave when the master is opened
-.RB ( posix_openpt (3)),
-so that nothing must be done by
-.BR grantpt ().
-Thus, no such helper binary is required
-(and indeed it is configured to be absent during the
-glibc build that is typical on many systems).
+glibc on Linux before glibc 2.33 could do so as well,
+in order to support configurations with only BSD pseudoterminals;
+this support has been removed.
+On modern systems this is either a no-op
+\[em]with permissions configured on pty allocation, as is the case on Linux\[em]
+or an
+.BR ioctl (2).
.SH STANDARDS
POSIX.1-2008.
.SH HISTORY
--
2.39.2
Attachment:
signature.asc
Description: PGP signature
