Hi!
On 2023-07-16 16:52, наб wrote:
> 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:
Michael wrote most of that corpus, and that's one of the very few
points where I disagree with him. I may have written myself some of
those, for continuity with the corpus, but I dislike it.
I may reform all of it to get rid of such cases. Let's add it to my
TODO list:
- 'Linux v[0-9]\+' (I see 5 cases.)
- Logic em dashes.
- Get rid as much as possible of \f.
- Transform the remaining \f into \f[].
- Split proc(5).
> $ 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)
nice catch :)
> 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.
Thanks! I'll review later.
Cheers,
Alex
> -- >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
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
