Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be careful of the examples you use. They stick

blog.thinkst.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Be careful of the examples you use. They stick

#101

Post by nottheengineer »

jmcqk6 wrote: post #81
hiAndrewQuinn wrote: post #76

Earlier quoted context omitted.

Is there a reason websites put that $ in front of commands you are fully expected to mindlessly copy and paste? I've seen it happen more and more and it simply baffles me.

> you are fully expected to mindlessly copy and paste I think this is the disconnect. Don't mindlessly copy and paste things. Take the time to understand what's going on.

I try to do that, but there are a lot of times where I find myself thinking "I don't care, I just want this to work" and blindly copy anything that's not super fishy. Especially after nvidia updates.

Re: Be careful of the examples you use. They stick

#102

Post by Terr_ »

SoftTalker wrote: post #91
andirk wrote: post #28

Can we please use `example.com` for an example domain name instead of like `somedomain.com`? It can create accounts with emails that someone can actually intercept.

Another "can we please" is stop illustrating (or providing as defaults) insecure configuration examples. A large percentage of people following the examples will use them verbatim. Had a case recently where someone was setting up a postgres container and the example was something like: docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres You guessed it, "mysecretpassword" ended up being t…

That could be improved if:

1. Software is coded to recognize "stupid example values" and prohibit them with an error or at least throw some pretty obvious warnings.

2. Such software also has a rarely-used but documented option to bypass the above checks.

For example, the PostgreSQL server might refuse to allow any DB user to have a password which begins with "password", returning a "Pick A Real One" error.

However somebody somewhere will always need the "don't do that" option: The more different libraries and services you bring together, the more likely there will be either false-alarms or outright conflicts between different example-blocker schemes.

Re: Be careful of the examples you use. They stick

#103

Post by kayodelycaon »

saurik wrote: post #19
gray_-_wolf wrote: post #17

Earlier quoted context omitted.

> Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century As in that it should be the default? Or only option? I personally do not have (and want to have) that set, and I am hardly alone. Any change in defaults fucks someone over, especially in things like bash, where you ssh into many machines with many different versions of bash...

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

I have the HIST_IGNORE_ALL_DUPS options set on zsh. I only need a history of what commands I have run, the order isn't important to me. Having the history be a unique set of commands makes it easier to dig through.

Re: Be careful of the examples you use. They stick

#104

Post by dylan604 »

jmcqk6 wrote: post #81
hiAndrewQuinn wrote: post #76

Earlier quoted context omitted.

Is there a reason websites put that $ in front of commands you are fully expected to mindlessly copy and paste? I've seen it happen more and more and it simply baffles me.

> you are fully expected to mindlessly copy and paste I think this is the disconnect. Don't mindlessly copy and paste things. Take the time to understand what's going on.

My favorite are the ones where the command is in a width limited element that needs to scroll so you can't see the full command to evaluate if you want to copy it or not. If the overflow has been properly set to scroll, it's doable, but I've seen the odd site where the overflow was hidden and you had to copy&paste it somewhere else just to see if you wanted to paste it in an actual terminal

Re: Be careful of the examples you use. They stick

#105

Post by Tobani »

cmovq wrote: post #99
superfrank wrote: post #94

> It’s important to realise this isn’t a customer-side issue; they shouldn’t have to consider the impact of every configuration option we choose to put in front of them. They don’t have the full context and knowledge, and expecting them to be experts in the nitty gritty of Canarytoken discoverability Yes! > Going forward, we will show multiple examples of prefixes. A user looking to add a custom domain will see a var…

> 2. Prevent users from using "someprefix" as the prefix and show them the warning again. Don't do this - examples in documentation should be valid. Having an example that doesn't work when the user tries it out will just lead to frustration.

I ran a blogging SaaS platform for a while. I had some instructions for configuring a reverse proxy to serve the blog. There were instructions for most major web servers. One step was adding a custom header.

- Go to and get your publisher ID - Add the following line to your config(replacing xxx-xxxx-xxxxx with your code from the previous step):

AddHeader X-Publisher-Id: xxxx-xxxxx-xxxxx;

We had a bunch of people leave the x's in and were confused why it wasn't working. So we made a blog that explained the misconfiguration, and replaced xxxx-xxxx-xxxxx in the documentations with that blog's ID. We got far fewer support requests after that.

Re: Be careful of the examples you use. They stick

#106

Post by OrderlyTiamat »

jabroni_salad wrote: post #100
hiAndrewQuinn wrote: post #76

Earlier quoted context omitted.

Is there a reason websites put that $ in front of commands you are fully expected to mindlessly copy and paste? I've seen it happen more and more and it simply baffles me.

As a generalist with many operating systems in use, I like that this tells you what OS the command is for. Especially now that powershell with its many unix-like aliases is getting popular, this isn't always evident.

> powershell with its many unix-like aliases

This choice simply baffles me. If I could just use those aliases and have it under the hood be PS calls- that's great! But that's not what's happening, instead it's a totally different command with different a different syntax and different flags. Why make it an alias at all‽

Re: Be careful of the examples you use. They stick

#107

Post by cduzz »

JohnMakin wrote: post #74

Reminds me of a large company I worked at, I had some documents for developers how to set up some local environment thing they had to do exactly 1 time and never again. It was just a handful of terminal commands, all starting with the traditional shell notation like: $ (some command) Over the course of a year I got periodic complaints that it "wasn't working" and I tried to find issues on my end and couldn't. One par…

For a long time I had my prompt some version of:

:$! $CWD $HOSTNAME $;

: (exit status, current directory, hostname, $ or # and a ;

the idea being -- you could just cut and paste and it'd mostly just work (except megabozos who like to make directories named ; or whatnot)

Re: Be careful of the examples you use. They stick

#108

Post by l0b0 »

kzrdude wrote: post #14
l0b0 wrote: post #11

This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist? Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century. Or should it be auto-generated, like Docker's container names? In the very best case, the defaults are so good that an empty configura…

How do we combine evolution and development with backwards compatiblity? I think it's quite natural that we end up with this conundrum. Like say for example Vim having outdated defaults, because changing them could disrupt existing users. A reboot/fork of it can reset and start fresh but will eventually in its own development hit the same problem. Are there examples of projects who solve this well? Ripgrep's author i…

Open source projects are terrible at this, in general. Any feature ever introduced, no matter how ephemeral or small an audience, can't ever be removed. Which I suspect has contributed to most GNU tools being kitchen sinks rather than doing one thing well.

Re: Be careful of the examples you use. They stick

#109

Post by msm_ »

pdw wrote: post #25
saurik wrote: post #19

Earlier quoted context omitted.

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

Now I'm confused. Why would you want duplicate entries in your command history? I get that on an overloaded system in the 80s it might have taken a perceptable amount of time to filter out duplicates. But on a modern system you surely want it always enabled?

I don't use bash so it's not applicable to me anyway, but why would I want it on? It's saving a few bytes of disk space, at the cost of ruining my history (the thing that the whole feature is about). At least fish's search feature is so awesome that I never had a problem with duplicate commands causing problems.

And I want my history untouched, because sometimes I forget how I solved something, go back a few months in my shell history and see the sequence of commands that I've used. I think that's a nice thing to have. And if I ever need history without duplicates, it should be easy to deduplicate it with a simple script.

Post reply on HN