5 ms·

> when I asked on IRC the only answer I got was 'man perldoc' Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or

by sltkr 11mo ago

> when I asked on IRC the only answer I got was 'man perldoc' Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables: HANDLE->autoflush( EXPR ) $OUTPUT_AUTOFLUSH $| If set to nonzero, forces a flush right away and after every write or print on the currently selected output channel. Default is 0 (regardless of whether the channel is really buffered by the system or not; $| tells you only whether you've asked Perl explicitly to flush after each write). STDOUT will typically be line buffered if output is to the terminal and block buffered otherwise. Setting this variable is useful primarily when you are outputting to a pipe or socket, such as when you are running a Perl program under rsh and want to see the output as it's happening. This has no effect on input buffering. See "getc" in perlfunc for that. See "select" in perlfunc on how to select the output channel. See also IO::Handle. Mnemonic: when you want your pipes to be piping hot Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.

chuckadams 11mo ago
That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.
- worik 11mo ago
  Golly There, the problem illustrated "You are not serrious" is a downright hostile attitude "man perldoc" as an answer can be translated as "f*^&%k off you stupid...."
  - deleted 11mo ago
    [deleted]
  - broken-kebab 11mo ago
    man perldoc is too curt, and therefore may feel hostile especially for native English-speakers who are used for polite communication to be more wordy. But cultural things aside it's actually a good working solution.
  - chuckadams 11mo ago
    > f*^&%k off Hey you're writing perl already! ;) Sorry for being salty earlier, but learning a language still takes at least a day or two of solid reading of the official manuals. https://perldoc.perl.org https://perldoc.perl.org if you want a web version.
    - debtta 11mo ago
      This is exactly the point. There was a fifteen year period where the best way of finding out what something meant in a programming language was to Google it. Pre-AI, post the predominance of newsgroups and offline documentation. Try googling "$|++". It just doesn't work. Never has. Now Google "file.flush". First hit is the answer you need on SO.
      - creer 11mo ago
        You did not need to google anything. The complete documentation was right there, next to the interpreter, on your machine. Ready for scanning and reading from top to bottom; and broken in sections that were actually relevant; and ready to search in bulk if you prefered with whichever local search tool you cared for. No need for google. (And google was run by python fans; probably saw no need to support searching for '$|++'.) And I notice "post the predominance of offline doc". Well that's one problem right there: As of 2025, there is still nothing that beats perl 5 docs as ~260 man pages. Probably LLM-based AI is getting there, at least for people who have difficulty with text. But for the rest of us, it's VERY useful to know that there is solid (offline) doc.
broken-kebab 11mo ago
Let me respectfully disagree. man perldoc would tell one needs to use -v key to learn about a var. And consequently perldoc -v '$|' would tell everything one needs to know about $| So it was actually reasonable advice.
- bawolff 11mo ago
  RTFM might be reasonable advice, but its not "welcoming" advice.
  - broken-kebab 11mo ago
    I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
  - maxlybbert 11mo ago
    I remember being very enthusiastic about helping people on, say, Stack Overflow. It didn’t take much extra effort to be nice and made me happy. But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it. Of course, getting the same question repeatedly may suggest something should be redesigned. I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
    - creer 11mo ago
      > getting the same question repeatedly may suggest something should be redesigned Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python). Better marketing of the documentation would have helped. I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.
throwaway173738 11mo ago
This comment kind of epitomizes the way the Perl community works, to be honest.
gosub100 11mo ago
The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.
- thyristan 11mo ago
  Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.
  - gosub100 11mo ago
    That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM. In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page. Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
    - thyristan 11mo ago
      Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well. Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code. Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.

by sltkr 11mo ago

chuckadams 11mo ago

That variable in particular gets covered in the Llama book as well. Anyone serious about learning perl in the 90's had at least one of the Camel or Llama books.

worik 11mo ago
Golly There, the problem illustrated "You are not serrious" is a downright hostile attitude "man perldoc" as an answer can be translated as "f*^&%k off you stupid...."
- deleted 11mo ago
  [deleted]
- broken-kebab 11mo ago
  man perldoc is too curt, and therefore may feel hostile especially for native English-speakers who are used for polite communication to be more wordy. But cultural things aside it's actually a good working solution.
- chuckadams 11mo ago
  > f*^&%k off Hey you're writing perl already! ;) Sorry for being salty earlier, but learning a language still takes at least a day or two of solid reading of the official manuals. https://perldoc.perl.org https://perldoc.perl.org if you want a web version.
  - debtta 11mo ago
    This is exactly the point. There was a fifteen year period where the best way of finding out what something meant in a programming language was to Google it. Pre-AI, post the predominance of newsgroups and offline documentation. Try googling "$|++". It just doesn't work. Never has. Now Google "file.flush". First hit is the answer you need on SO.
    - creer 11mo ago
      You did not need to google anything. The complete documentation was right there, next to the interpreter, on your machine. Ready for scanning and reading from top to bottom; and broken in sections that were actually relevant; and ready to search in bulk if you prefered with whichever local search tool you cared for. No need for google. (And google was run by python fans; probably saw no need to support searching for '$|++'.) And I notice "post the predominance of offline doc". Well that's one problem right there: As of 2025, there is still nothing that beats perl 5 docs as ~260 man pages. Probably LLM-based AI is getting there, at least for people who have difficulty with text. But for the rest of us, it's VERY useful to know that there is solid (offline) doc.

broken-kebab 11mo ago

Let me respectfully disagree. man perldoc would tell one needs to use -v key to learn about a var. And consequently perldoc -v '$|' would tell everything one needs to know about $| So it was actually reasonable advice.

bawolff 11mo ago
RTFM might be reasonable advice, but its not "welcoming" advice.
- broken-kebab 11mo ago
  I agree in general (and already commented on this). But some people believe it's like giving fish instead of fishing rod. And I think it was prevalent idea in tech circles during 90s-00s that people who don't read that fm waste other participants time, and needlessly multiply forum topics or extend conversation history. Which was seen as uncivil behavior in those times.
- maxlybbert 11mo ago
  I remember being very enthusiastic about helping people on, say, Stack Overflow. It didn’t take much extra effort to be nice and made me happy. But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it. Of course, getting the same question repeatedly may suggest something should be redesigned. I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
  - creer 11mo ago
    > getting the same question repeatedly may suggest something should be redesigned Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python). Better marketing of the documentation would have helped. I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.

throwaway173738 11mo ago

This comment kind of epitomizes the way the Perl community works, to be honest.

gosub100 11mo ago

The problem is with man pages themselves. You shouldn't have to read 100% of something to find 0.1% of something. In fact, this concept is covered extensively in CS theory about sorting. Reading a manpage is less efficient than asking someone who already knows.

thyristan 11mo ago
Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.
- gosub100 11mo ago
  That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM. In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page. Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
  - thyristan 11mo ago
    Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well. Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code. Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.