55 comments

[ 1.9 ms ] story [ 124 ms ] thread
[flagged]
It made me chuckle, maybe take a joke?
It's unfortunate, but I know many people in my life who have been sexually abused and raped. I'm more sensitive to sexual jokes because of it. My intent here is to push the author past the easy joke title which can make women feel uncomfortable to be in this area of the internet.

Tech is very male dominated and the more inclusive we are the more ideas we bring to the table.

> Tech is very male dominated and the more inclusive we are the more ideas we bring to the table.

Tech has been bending over backwards for quite a while, but to no avail.

In contrast, marketing, law, medicine etc used to be very male dominated a few decades ago, made almost no attempt at welcoming women, and still got many of them.

It's almost as if women make their own choices, and it's not really down to how welcoming specific fields are? It's almost as if women have preferences of their own? Who would have guessed?

See https://slatestarcodex.com/2017/08/01/gender-imbalances-are-... and https://slatestarcodex.com/2017/08/07/contra-grant-on-exagge...

Do you think people make their own choices on where to work based on how comfortable they feel working in that environment?
Partially. But obviously lots of other factors are important.

Have a look at the slatestarcodex essays for more detail. Scott Alexander writes better than me.

> Tech has been bending over backwards for quite a while, but to no avail.

You're applying a false equivalence here. Some things are positive changes and make sense, and some are not. Grouping everything together isn't helpful.

I am male, and my first thought on reading the title was that it was juvenile to a point that I was surprised to see it as a title on HN. Hearing someone else echo that feedback is helpful and will hopefully help the author in their growth.

This is not a "bend over backwards" request, it's a dumb sexual joke on HN, and your response comes across as very condescending.

(comment deleted)
For what it's worth, I even partially agree with you.

I went back and noticed that the original comment is dead and flagged now. So I 'vouched' for it: I don't entirely agree with the contents, but I think it is part of a good debate.

I googled ^D and didn't find any other meaning other than ctrl-D?

Some places said a D is short for Dick, but I don't see why that would be especially offensive to abuse victims because it seems to be used in a flirtatious way, not an abusive way.

To give context, it's a reference to "getting the D" or "giving the D" which is slang for getting/giving someone 'dick' which is inappropriate considering this is a post about terminals.
This is why tech bro culture persist.
I initially didn't get either of you, all I can think of was a half-face emoticon. It turns out that "getting the D" means something (I'll refrain from explaining this), and with this context "take a joke" is really unacceptable---it means you know the joke and you think it's fine, which isn't.
I don’t really get why this is so offensive. It’s some guy’s webpage, where we are just visitors, on which he has shared some knowledge with a title that plays on a double entendre. It’s not about taking a joke as it’s not something addressed to you at all. People need to stop being hall monitors on the internet. Just close the page, move on.
The title makes some absolute sense, so it is per se acceptable. You may take this case as a reminder to remain focused and disregard unnecessary potential lateral reads.
I didn't take offense to the title; it is not even clear whether the author intended that joke (I didn't know that phrase so could the author). I merely pointed out that, if you think the author intended this particular joke, then it is inappropriate to say "take [the] joke".
[flagged]
Although, some of us had to actually think for a while to notice what may have triggered your comment.
Oh, the "guess what I was thinking" game again.

Ok, guessed: if your mind has filthy lenses, sniper, do not ask us to join you in your avoidable traits.

(comment deleted)
The author takes the long way round and misses the point by a little bit.

ANSI C defines EOF, the 2nd edition by Kernighan and Ritchie page 151 states 'getchar returns the next input character each time it is called, or EOF when it encounters end of file. The symbolic constant EOF is defined in <stdio.h>.

The value is typically -1, bit tests should be written in terms of EOF so as to be independent of the specific value.'

The discussion is about how terminals and pseudo terminals handle control characters, specifically ^D / EOF / termios.c_cc[VEOF] which is a few layers below getchar(). man stty(1) or termios(5) for more information.
EOF is also used to indicate error(s) in a stream.

Its value is platform dependent. As per the C++ standard[0]:

  It is a macro definition of type int that expands into
  a negative integral constant expression (generally, -1).
0 - https://cplusplus.com/reference/cstdio/EOF/
please do not use cplusplus.com, use cppreference instead. cplusplus.com often is wrong, out of date, or just missing things.
does the program not simply receive ^D as a normal character? I thought i was up to the program to interpret it
It does not. Its still up to the program with how it wants to deal with end of file though.
When a program reads from a pseudo-terminal device in "cooked mode"[0], ^D is the default control character to indicate "no more input will be made available."

A program reading from a file handle other than a pseudo-terminal or a pseudo-terminal set to be in "raw mode" will behave as you describe.

0 - https://en.wikipedia.org/wiki/Terminal_mode

Yes but the expectation still is to interpret it as "end of input", even for interactive programs. One that doesn't (unfortunately) is zsh where ^D makes autosuggest prompt "do you wish to see all n possibilities?"
I like how he references Linus' TTY Demystified article (a popular repost here on HN too) --- that has almost become a de-facto source of information on the details of how the TTY subsystem works.
Very interesting, my naive assumption up to now had honestly been that ^D was just the shortcut for a NULL byte, 0x0 and everything just thus assumed it’d reached the end of the stream and finished up based on that.

Sending a special EOT 0x4 that gets special terminal and kernel handling feels just a little less… elegant… than what I had imagined.

I am curious now, would it be possibly to make a keyboard generate a NULL byte either by existing keyboard shortcut or custom hardware - and how the system would handle it? My guess would be that keyboards sending NULL might not be possible over keyboard protocol at all but I genuinely have no idea.

Please look at ascii table to see why ctrl-{key} sends a corresponding control code and why the modifier is called “control”: https://www.commfront.com/pages/ascii-chart
The article explained it well enough. Makes sense, I just was unaware. From that chart though then could ^` generate a NULL byte?
The chart also lists the control key combination for each control byte, for NUL, it's C-@.
If EOF was a character, you couldn't process (binary) streams that contain the character.

^@ produces the NUL character.

"I am curious now, would it be possible to make the keyboard generate a NULL byte either by existing keyboard shortcut or custom hardware - and how would the system handle it?"

Not sure I understand the point of the experiment, but in NetBSD kernel one can remap the keyboard, e.g., set a key to 0x00. How to do this in Linux kernel is a question for reader.

https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev...

The NUL byte has no special meaning in file I/O, or the terminal. (Historically, the only special meaning was as a no-op character that does nothing.) The convention of using NUL as a termination character only exists for in-memory strings in C, and has no connection to file I/O.
> the process has to be programmed to stop if read returns no bytes. A process could carry on regardless, or not read stdin at all. In Bash, if you type half a command and press ^D repeatedly, nothing happens.

It's not a good example, because bash disables the canonical mode. When you type ^D this happens:

  read(0, "\4", 1)                        = 1
(And then bash ignores the read EOT character.)
Author here. You're correct. I've added a footnote to that part now. I think it still illustrates the point so I've left the main text alone.
See also the evil interview question, "how does a keyboard type characters into an Emacs buffer?"

You could spend 8 hours describing it from power, to USB descriptors, to debouncing, to keymapping, to matrix scanning, to ptys, to editor string management algorithms to Lisp. And passing by this article as well!

Do you have a link? I can't find anything under that title.
Nah it's just an interesting interview question if you are looking for a generalist. There's also "what happens when you type into the address bar of your browser and hit return?" Can cover DNS, wifi, BGP, servers, DOM layout, TLS, etc.
The `c_cc` array is configurable via the stty command or the termios(3) API.

To override the character for "EOF," change ^D to something else in the following command and run it:

  stty eof ^D