Hacker News new | past | comments | ask | show | jobs | submit login

Every project I develop is unit tested with strings containing invalid unicode text, containing null bytes, and other random stuff.

If a user can’t paste any byte sequence, and expect it to work, then the tool is broken. I handle these cases.




You can do it. The question is whether you should if you can avoid it.

When writing a shell script or makefile to deal with repetitive tasks if is easier to assume some things.


I'd prefer it if the writer of the shell or make didn't make too many assumptions about my assumptions.

Even bash lets you escape unusual filenames for when you need them. Make will always explode your strings, and doesn't even attempt to let you escape them. I don't think it's unreasonable to expect a time-tested Unix tool dealing with files to actually handle all possible files.


So in order to deal with the real world possibility of spaces in filenames you choose to ditch a real world, useful tool?

Perfectly reasonable if spaces in filenames are a hard req.

In lots of scenarios they are not, and I prefer to assume that filenames have no spaces, and stick to make.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: