"-w" changes visual wrapping, it doesn't save that way. No different than the behavior of "cat" in an interactive terminal really, beyond the temptation for editor religion.

> "-w" changes visual wrapping, it doesn't save that way. No different than the behavior of "cat" in an interactive terminal really, beyond the temptation for editor religion.

What you mentioned is "soft wrapping", which is visual only but doesn't affect the saved file. But the default for nano when I first encountered it was "hard wrapping", which does affect the saved file. Some distributions later changed the default in the nano configuration file, but depending on the configuration file instead of a built-in default is risky. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135978 (and the five other bug reports merged into it) for an example of the problems caused by running nano in the default configuration without disabling its line wrapping.

I stand corrected on the wrap behavior of the original nano 1.x. Softwrap and the default wrap mode change weren't added until later.

That's interesting. I haven't ever had that problem. I have had a ton of problems with zsh adding characters to things like SSL certs (I forgot, maybe an ending %?) where I had to switch back to bash to base64 encode/decode it properly.

I write the standards for our engineers to follow/emulate/consider. I don't have very much for nano but this is what I put into every containers userdata scripts. I can't get this curl command to show up correctly.

  # Add syntax highlighting and line numbers to nanorc, need to fork syntax repo so we're not installing random git repos

  curl 

https://raw.githubusercontent.com/scopatz/nanorc/master/inst... | sh

  {
  echo set constantshow
  echo set linenumbers
  } > ~/.nanorc

If I recall correctly that default changed awhile back. One could also set it how they want in nanorc.

However, I do understand the criticism, and how that could leave a bad first impression.