Forms of Insanity

For the purposes of this page, I am defining insanity as taking actions which work directly against your goals. People do this surprisingly often. This page will attempt to collect examples and categorize them.

Note that the common feature of each example here is that the person did not achieve their goal. If the goal was to get help with some programming question, then the person went away without being helped (as far as we could determine), or took much longer to get a helpful answer. There are no other criteria by which the example is measured.

By collecting these examples, I hope to provide some guidance. If you can recognize these behaviors in yourself, then you may be able to avoid falling prey to them.

This page is a work in progress.

Table of Contents

  1. Withholding Information
  2. Misrepresenting the Problem
  3. Rejecting the Answer
  4. Insulting the People Who Help You
  5. See Also

Withholding Information

When asking for help with a project or problem, you have to be willing to reveal some of the details of your project/problem. Otherwise, your requests are too vague for anyone to answer. This seems like common sense to those of us trying to answer, but the people seeking answers don't seem to see it this way.

Remember, we can't read your mind. You may think the goal is crystal clear, because you understand it; but we don't understand it yet. If we ask for clarifications, it's because there are still many possible goals you could be trying to achieve, and we don't yet know which one you are pursuing. It's not in your best interest for us to simply guess a goal and give an answer that may be completely wrong for you. This wastes our time as well as yours.

In the case of a technical problem, we need specific details to be able to diagnose and solve the problem. A given symptom might have many possible causes, and we need to narrow them down. Even worse, if we think the symptom is caused by Problem A, and we give a solution for Problem A, but the actual cause is Problem B, then the solution we give may either do nothing at all, or may actually make things worse.

15:34  asdf0101> hello guys; i need to build a command line; command name and 
                 its parameters are prompted from user (i've simplified a bit); 
                 what's the best way? do i need to build a string, appending 
                 using printf %q? or should i build an array this way? do i 
                 need to exec `> eval "${cmd[@]}"` or simply `> "${cmd[@]}"` 
                 will do? i'm a bit confused
15:34  hyper_ch> build a command line?
15:34  hyper_ch> !args
15:34  greybot> Understanding Arguments and Word Splitting:
                http://mywiki.wooledge.org/Arguments
15:35  greycat> Why are you prompting users for commands and executing them?  
                That's what shells do.  Let the user just run a shell.
15:35  asdf0101> hyper_ch: build a program invocation line?
15:36  hyper_ch> still no idea
15:36  greycat> What are you doing?  What kinds of commands?  Why?
15:36  hyper_ch> what you mean
15:36  asdf0101> greycat: i don't, literally; the command is selected during
                 runtime based on the user actions
15:37  greycat> 15:34  asdf0101> hello guys; i need to build a command line;
                command name and its parameters are prompted from user
15:37  asdf0101> greycat: it's not the point really
15:37  greycat> Give an example of the MOST COMPLEX command you ever want to be
                able to execute in this way.
15:37  asdf0101> based on the input by user <=> prompted from user
15:38  greycat> Give an example of ANY FUCKING THING already.
15:40  asdf0101> greycat: fuck you, idiot; are you a moron? i admit this, i 
                 haven't put the magical phrase "explain how the quoting works 
                 and how to make it right" in the original question; i just 
                 presumed the presense of `printf %q` + `eval` would help you 
                 glean the idea; anyway, fuck you all

Of course, this phenomenon is not limited to IRC. Here are some excerpts from an email thread.

From: Brian

> Addendum:  during my Jessie install, the install program commented at one point:
> "There doesn't seem to be any other OS on your system".  Jeez!!  I hope some
> maintainer reads this complaint and Debian  works hard to make sure that the

What is the exact name and version of this OS which is not found?

> operation of installing a second OS(Linux) on a Windoze box is as easy and
> error-proof as it is possible to make it.

1. As a user do

     dpkg -l | grep grub

   Please post the output of this command.

2. Suppose there are four packages listed. As root do

     apt-get --reinstall install <package_name>

   for each package

   <package_name> is in the second column of the 'dpkg -l' output.

   So, for example

     apt-get --reinstall install grub-common
     apt-get --reinstall install grub-pc
     apt-get --reinstall install grub-pc-bin
     apt-get --reinstall install grub2-common

   is what I would do on my machine. For the grub-pc reinstall please post
   the lines which begin "Found ....." in the output.

3. As root run the command

     os-prober

   and post its output.

===============================================================================
From: Alan

...
       <LOL>  Windows 10.  If there is a more exact name, I don't know it.

...
         Why?  why all this?  What good will it do? to anyone?  To do this I'd have
         to get out of this URL(mail.his.com), shut down my Windoze, reboot to Jessie,
         copy the output you are requesting to a piece of paper, and then get back here.(*)

         May I ask: are you the Debian installation maintainer?  if you are, I'd be
         happy to work with you.

===============================================================================
From: Brian

> Warning:  This E-mail is for the most part in the nature of a pushback against
> various insinuations that have been made.

Warning duly noted; most of this mail is snipped so we can concentrate
on the technical aspects of your issue.

[...Snippety-snip...]

> Again, for the third time:  I hope that an new release of the Debian installation SW
> will be able to detect when another OS is already on the system, and that a proper and
> simple procedure will be put in place for e.g. newbies to Linux or to dual-bootable
> systems to be able to choose between the systems immediately after the machine self-test.

You were asked for some information. You declined to provide it. As a
route to solving a technical problem your response leaves a lot to be
desired.

The output of interest is from os-prober. You know what it, unless you
are so uninterested in seeking a solution you haven't even run it or are
keeping what it says to yourself.

If you had clue and had provided a decent, useful response you would
then have been directed to read /usr/lib/os-probes/mounted/20microsoft.
The light would then have dawned (perhaps). All the time you would be
learning and helping yourself. But no - whinging wins out. Far easier
for you to that than think for yourself.

This particular exchange lasted several days, with most of the messages achieving nothing at all. There were other responses similar to Brian's last one, but I chose this one for its directness and clarity.

Here's another example from IRC. I have omitted some of the discussion due to the length:

15:33  jaggz> anyone know how files in ~/.local/bin are being run, when it's 
              not in my path?
15:34  jaggz> I have a command, installed with python's pip install command.. 
              "which thatpackage" doesn't show it, but running "thatpackage" 
              works, and I do find it in ~/.local/bin
15:34  greycat> Aha, fundamental error revealed.  You are using which.  Use 
                type instead.
15:35  znf> hmm, what is which doing different than type?
15:35  nchambers> !which
15:35  greybot> which(1) is an external program used to search PATH for an 
                executable. It behaves differently on different systems and you 
                can't rely on a useful exit code; use (from most to least 
                portable) ''command -v'' or ''type -P'' (to find the path) or 
                ''hash'' (to check) instead. See 
                http://mywiki.wooledge.org/BashFAQ/081
15:35  greycat> For starters, which is external.
15:35  nchambers> secondly, its not standard
15:37  jaggz> type is showing that it's in ~/.local/bin too
15:37  greycat> jaggz: what's the NAME of this command?  What does "type 
                thename" say?  No -P option.  Just type.
15:38  jaggz> hashed to that ptah
15:38  greycat> Why is this a FUCKING SECRET
15:38  jaggz> the name is googleimagesdownloader :)
15:38  greycat> So type says "googleimagesdownloader is hashed 
                (/home/you/.local/bin/googleimagesdownloader) ?
15:38  jaggz> no secret.. but not relevant
15:39  greycat> The exact output of type is THE ONLY RELEVANT THING.
15:39  jaggz> googleimagesdownload is hashed 
              (/home/jaggz/.local/bin/googleimagesdownload)
15:39  greycat> OK, so it is external (not an alias, function, builtin or 
                keyword) and it is in your $PATH, or it was at the time bash 
                hashed it.
15:40  greycat> Next question is, what's $PATH set to?
15:41  jaggz> oh.. crap. it is in my path.
15:41  jaggz> why's which not show it then?
15:41  greycat> what does which say?
15:42  jaggz> no output
15:42  greycat> did you make a typo in the name, like you did the first time 
                you said it in IRC?
15:42  jaggz> no I tab completed the name
15:43  nchambers> why care what which says?
15:44  greycat> Because it might help us figure out the answer to his question, 
                which is "why doesn't which give me the answer I expected".
15:44  greycat> But since he does not paste the exact command used, the exact 
                output, or the exact contents of $PATH, it's like pulling teeth.
15:47  jaggz> Maybe which doesn't expand the ~  for the home dir?
15:48  greycat> You have a literal ~ in $PATH?
15:48  greycat> 15:44  greycat> But since he does not paste the exact command 
                used, the exact output, or the exact contents of $PATH, it's 
                like pulling teeth.
15:48  jaggz> greycat, yeah
15:48  greycat> FUNDAMENTAL PROBLEM #2 REVEALED
15:49  greycat> Now imagine how much time we could have saved if you had simply 
                pasted $PATH when I asked you to.

Misrepresenting the Problem

Misrepresentation of the problem comes in many forms. Probably the most common is selection of an "example" that is made up on the spot, but which lacks the pertinent features of an actual example. It would be better to show a real example, but people seem to be extremely unwilling to do this.

<skrp> what is the proper way to set a variable; i find myself stuck in this
       route; variable=$( cat $file | awk '{ print $1 }' ); this form is bad
       for error checking
<greycat> read -r variable _ < "$file"
<skrp> are strings of cmds assigned to a variable a job for fns
<greycat> Ignoring the second question.
<skrp> greycat, that example was trying to encaplusate the idea of the 'second
       question'
<skrp> are sequential cmds to produce one output into a variable only
       performed well with functions?
<greycat> Then it's a horrible example.  What are you trying to do?
<geirha> depends on the case
<greycat> What do you want to put in the variable?
<skrp> variable=$( cat 1 2 3 >> tmp | sed 's/^4//' || printf "error in cat
       cmd\n" )
<greycat> Stop typing gibberish and describe what you want to accomplish.
<skrp> well its the general idea. i always set my variables as ive done, but
       it is crappy for error checking
<greycat> Your sed command doesn't even receive any input.
<greycat> It's 100% gibberish.
<skrp> variable=$( cat 1 2 3 >> tmp | sed 's/^4//' tmp || printf "error in cat
       cmd\n" )
<greycat> THE PIPELINE IS FUCKING IDIOTIC.
<greycat> YOU ARE BEING AN IDIOT
<geirha> now sed sometimes have input
<skrp> calm down geez
<skrp> if you dont want to help dont respond
<greycat> *plonk*
<greycat> Done.

...

<watersnorks> maybe his english isn't very good
<geirha> You can check the PIPESTATUS array immediately after the pipeline
<greycat> watersnorks: if the checking is concerning the length of the
          variable, I would check that with a test or [[ command after the
          assignment.  If the checking is concerning the exit status of the
          command then I would go on that.
<larryv> you don't have to shove everything into the $( )
<geirha> and/or you can enable the pipefail set option, but if you use set -e,
         you're life becomes even more hellish than set -e alone
<larryv> break it up
<geirha> gah, *your
<majuscule> nice, i didn't know about PIPESTATUS
<greycat> Maybe his REAL FUCKING PROBLEM is that he keeps using dumb-as-shit
          pipelines to produce output instead of just reading the variable out
          of a file with read.
<geirha> cat file | somecmd   can of course, always be reduced to just run
         somecmd; the cat is redundant
<majuscule> skrp: do the assignement as you were in the beginning, and then
            check the contents of the variable afterwards
<watersnorks> skrp: you could use ${param:-word} to set a default, or test's
              -z -n etc, or [[ -n "$foo" ]] || fuck_this_shit
<watersnorks> one too many or there
<larryv> in the general case, use intermediate variables. check each command
         separately. don't shove pipelines into $( ) where you lose
         information afterwards
<larryv> and in this case, just use "read"

...

<greycat> watersnorks: And as far as "english is bad" as an excuse, it's a
          weak excuse.  If he wants to ask how to abort the script if command
          "a" fails in the assignment var=$(a | b | c) then he should just use
          THAT example instead of making up some crap involving cat and awk.
<watersnorks> greycat: yeah i understand, sorry
<greycat> No, it's not your fault... it's his.
<greycat> If I had to ask for help in a Spanish-speaking channel (my Spanish
          is incredibly poor) I would use very simple words and simple but
          *representative* examples.
<geirha> var=$(a | b | c) ???? por favor
<osse> si!
<greycat> I has var=$(a|b|c) if a exits fail I want script exit
<greycat> That's all you have to say.

There were multiple communication problems here, but the biggest problem was the misrepresentation of the problem with a bogus example. An experienced bash scripter reading the question sees the intent behind the example as "I am reading two variables from a file" and rewrites the code to do that in a simpler and more efficient way. But if the real problem is "I want to check the exit status of each command in a pipeline" then the example completely fails to convey this goal.

Of course, the goal was also flat-out misstated in the first place: "what is the proper way to set a variable". When the goal is stated incorrectly, don't be surprised if the answers don't work.

11:00  rnd> hellouz
11:01  rnd> input: 00000000123232.jpg
11:01  rnd> output: 123232.jpg
11:01  rnd> length always fixed, 13 chars
11:01  greycat> Oh!  That makes it simpler.
11:01  rnd> 13 chars (numbers) + extension .jpg
11:01  rnd> i used to ask for someting similiar
11:02  greycat> But your example has 14 characters before the dot.
11:02  greycat> So... that makes it HARDER again because now we can't believe 
                anything.
11:02  rnd> im sorry
11:02  rnd> 8027501757204.jpg
11:02  rnd> real example
11:02  greycat> WHHHHHHAAAAAT
11:03  rnd> 8027501757204.jpg
11:03  rnd> this is my filename input
11:03  greycat> So "trim the leading zeros" was NOT the goal?!?
11:03  rnd> i need the output 757204.jpg
11:03  rnd> im sorry, no

I suspect most programmers seeing the original "input" and desired output would assume the question is about how to trim an indeterminate number of leading zeros, rather than how to select a substring based on character count. The example was not only factually incorrect (wrong number of characters), but misleading because it represents a completely different problem than the one being asked.

Need another example? Here's someone who wrote some perl code, and then had concerns about its safety:

<Soliton> newvar=$(printf %s "$var" | sed 's/\([^[:alnum:]]\)/\\\1/g')  # is
          newvar safe to inject now?
<Soliton> it certainly escapes too much but i can't see a way to exploit it.
<kurahaupo> Soliton: newvar=${var//[^[:alnum:]]/}
<kurahaupo> Err, [![:alnum:]]
<geirha> inject where?
<kurahaupo> # var=$':-;$\\@\n*' ; echo "${var@Q}"
<shbot> kurahaupo: $':-;$\\@\n*'
<kurahaupo> # var='hi;rm everything'; newvar=$(printf %s "$var" | sed
            's/\([^[:alnum:]]\)/\\\1/g') ; IFS=\\\  ; echo $newvar
<shbot> kurahaupo: hi ;rm everything
<Soliton> geirha: into a shell command.
<geirha> just use single quotes
<kurahaupo> Soliton: injected like that ↑ ?
<Soliton> the quoting is not up to me.
<geirha> q=\' quoted=$q${var//$q/$q\\$q$q}$q
<Soliton> the quoting is not up to me.

... what does that even mean? You are quoting something but you don't get to choose how you quote it?

<Soliton> kurahaupo: well, with proper quoting of the expansion.
<geirha> by adding backslashes you are already quoting
<Soliton> i'm not adding the backslashes.
<geirha> that sed is ...
<Soliton> that is an existing feature and i'm wondering how safe it is.
<geirha> ah
<geirha> won't handle newlines
<Soliton> it's really trigger.pl, a script for irssi.
<greycat> so you're free to just rewrite it... also, why would a perl script
          call sed?
<kurahaupo> Soliton: Perl has quotemeta
<Soliton> that was my poor way of showing what it does in shell terms.
<greycat> #perl
<Soliton> the perl is done. i have no question about it.
<kurahaupo> Except whether its results are safe?
<Soliton> yes.
<greycat> Lying to us and translating perl into sed and then showing us the
          made-up sed that does not actually exist is not a productive use
	  of anyone's time.

So, apparently this person wrote some perl code, and then had some questions about it, so he went to the #perl channel and... no, wait. That's not what happened. He went to the #bash channel, made some attempt to translate the perl code into sed, and then asked about the sed command.

Why do people do this?

Rejecting the Answer

When you ask someone a question, and they give you an answer, why would you immediately reject the answer? Did you already know the answer before you asked (or think you did)? Then why did you even ask?

13:56   lungaro> can bash unhex a string ? ie, h=ffff; echo -e "\x$h" <-- does
                 not work as expected
13:56   greycat> !faq hex
13:56   greybot> http://mywiki.wooledge.org/BashFAQ/071 -- How do I convert an
                 ASCII character to its decimal (or hexadecimal) value and back?

All done, right? The answer was given... but then rejected.

13:56  lungaro> i dont want decimal, I want binary
13:57  greycat> you just wrote ffff which is not binary
13:57  lungaro> i want hex string to byte sequence
13:57  greycat> you also used the word "hex" in your question, and the
                variable's name was h
13:57  lungaro> Yes. I want to convert h to bytes
13:57  lungaro> pay attention =P

And now arrogance! Really? How is this helping you?

13:57  greycat> !faq hex
13:57  greybot> http://mywiki.wooledge.org/BashFAQ/071 -- How do I convert an 
                ASCII character to its decimal (or hexadecimal) value and back?
13:59  lungaro> that FAQ is not applicable, I want xxd but in bash
13:59  lungaro> echo ff | xxd -r -p
13:59  greycat> *plonk*
14:01  prussian> ?
14:01  greycat> I'm guessing he didn't read the bot's entire line, where it 
                says "and back".

There's another variant of this, which I see frequently: the person asking the question has a preconceived idea of the solution they want to see, and any solution you give which doesn't match what they expect will be rejected.

16:01  hseg> and when i realized that i'm basically using awk here as an 
             overglorified split; paste, i tried to find a bash way of doing 
             columnwise operations
16:02  hseg> which is split; past
16:02  greycat> while IFS=whatever read -r f1 f2 f3; do ...; done
16:03  hseg> greycat: stylistically, i dislike that. i acknowledge it's *a* 
             way of solving the problem, probably the bash way at that

This is a bad start!

16:04  hseg> kerframil: basically, i want to take a tsv file, split it into 
             columns, send each column to a different pipeline, then join the 
             pipelines together at the end
16:04  greycat> what
16:04  kerframil> hseg: "split it into columns". the line is already an 
                  expression of a series of columns. this is the first thing 
                  that isn't clear.
16:05  greycat> what in the hell kind of DATA do you have, that you process 
                each column independently of everything else on the same line
16:06  hseg> greycat: consider eg wanting to normalize only the date column of 
             a tsv file
16:06  hseg> kerframil: given a file foo\tbar\nquz\tzop\n..., i want to pass 
             foo\nquz\n... to one pipeline and bar\nzop\n... to the other
16:06  greycat> hseg: while IFS=$'\t' read -r f1 f2 f3 date f5; do 
                date=$(...); printf '%s\t%s\t%s\t%s\t%s\n' "$f1" "$f2" "$f3" 
                "$date" "$f5"; done
16:07  greycat> hseg: you're giving two COMPLETELY different problem 
                descriptions here
16:07  hseg> i get that that's the accepted way of doing things. i probably 
             will end up doing either that or doing it all in awk
16:07  hseg> but i'm asking if this third way could possibly work

At this point, there is no point trying to help. If you want to do things in a way that you know is wrong, but which you think will be amusing or clever, just do it yourself. Don't expect people to help you with your descent into madness.

Insulting the People Who Help You

Sadly, this is actually a thing. Usually it accompanies rejecting the answer.

16:49  beeman> hi. how can i print something before grep on same line without
               using variables, is it possible? In this example: strings filexe
	       | grep 'yel' and before each pattern I want to print the
	       filename with ': ' and then the match. Is it possible? How to do
	       that?
16:50  greycat> beeman: awk '/yel/{print "filexe: ", $0}'
16:50  beeman> why awk?
16:50  beeman> all answers to what I search using awk. How can I do that with
               grep?
16:50  greycat> oops, the comma adds an extra space.  remove the literal space
                in the string constant.
16:51  greycat> !Using
16:51  greybot> "How can I do X using Y?" NEVER ask a question of that form. Y
                may not be the best way to do X. All you should ask is, "How do
		I do X?"
16:51  beeman> Because you don't know an copy from stack overflow?
16:51  greycat> *PLONK*
16:51  greycat> Fucker.

If you have already researched the topic, and all the results agree that one particular approach is best, and then you ask and get the same answer, maybe -- just maybe -- the answer is actually correct.

If you don't understand the answer, then feel free to ask for clarification. Do not insult the people who are giving you the correct answer. This just makes them stop helping you. It may even get you kicked out of the community (mailing list, chat room, forum, or whatever).

See Also

In no particular order: