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

Stop writing CLI validation. Parse it right the first time

hackers.pub

Post reply on HN
Print view View original

111–120 of 169 posts

Re: Stop writing CLI validation. Parse it right the first time

#111

Post by Sharlin »

MathMonkeyMan wrote: post #94
bschwindHN wrote: post #82

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is co…

Sure, but Rust specifically uses static linking for everything but the very basics (ie. libc) in order to avoid the DLL hell.

Re: Stop writing CLI validation. Parse it right the first time

#112

Post by perching_aix »

bschwindHN wrote: post #82

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

Like shell scripts? Cause I mean, I agree, I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Just probably not what you meant.

Re: Stop writing CLI validation. Parse it right the first time

#113

Post by vvillena »

dcminter wrote: post #86
majorbugger wrote: post #84

Earlier quoted context omitted.

I will keep writing my CLI programs in the languages I want, thanks. Have it crossed your mind that these programs might be for yourself or for internal consumption? When you know runtime will be installed anyway?

You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use. My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling. Internal to work? Yeah, Java's going to be an easy sell. I don't think OP necessarily meant it as a political statement.

This is not an issue with Java and the other JVM languages, it's simple to use GraalVM and package a static binary.

Re: Stop writing CLI validation. Parse it right the first time

#114

Post by k3vinw »

dwattttt wrote: post #73
8n4vidtmkvmk wrote: post #66

Earlier quoted context omitted.

Everyone seems hung up on the type system, but I think the validity of the data is the important part. I'd still want to convert strings to ints, trim whitespace, drop extraneous props and all of that jazz even if I was using plain JS without types. I still wouldn't need to check the inputs again because I know it's already been processed, even if the type system can't help me.

The type isn't just there to make it easy to understand when you do it, it's for you a year later when you need to make a change further inside a codebase, far from where it's validated. Or for someone else who's never even seen the validation section of code. I'm hung up on the type system because it's a great way to convey the validity of the data; it follows the data around as it flows through your program. I don'…

jsdoc types are better than nothing. You could switch to using Typescript today and it will understand them.

Re: Stop writing CLI validation. Parse it right the first time

#115

Post by jappgar »

I really think parse don't validate gives people a false sense of security (particularly false in dynamic languages like javascript and python).

"Well, I already know this is a valid uuid, so I don't really need to worry about sql injection at this point."

Sure, this is a dumb thing to do in any case, but I've seen this exact thing happen.

Typesafety isn't safety.

Re: Stop writing CLI validation. Parse it right the first time

#116

Post by perching_aix »

bschwindHN wrote: post #106
majorbugger wrote: post #84

Earlier quoted context omitted.

I will keep writing my CLI programs in the languages I want, thanks. Have it crossed your mind that these programs might be for yourself or for internal consumption? When you know runtime will be installed anyway?

That's fine, I'll be avoiding using them :)

You'll avoid using his personal tooling he doesn't share, and his internal tooling he shares where you don't work?

Are you stuck in write-only mode or something? How does this make any sense to you?

Re: Stop writing CLI validation. Parse it right the first time

#117

Post by mjevans »

bschwindHN wrote: post #107
MathMonkeyMan wrote: post #94

Earlier quoted context omitted.

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is co…

Yes but I've never had a native tool fail on a missing libc. I've had several Python tools and JS tools fail on missing the right version of their interpreter. Even on the right interpreter version Python tools frequently shit the bed because they're so fragile.

I have. During system upgrades, usually along unsupported paths.

If you're ever living dangerously, bring along busybox-static. It might not be the best, but you'll thank yourself later.

Re: Stop writing CLI validation. Parse it right the first time

#118

Post by craftkiller »

MathMonkeyMan wrote: post #94
bschwindHN wrote: post #82

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is co…

Don't let your dreams be dreams

  $ wget 'https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz'
  $ tar -xvf 'ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz'
  $ ldd ripgrep-14.1.1-x86_64-unknown-linux-musl/rg
  ldd (0x7f1dcb927000)
  $ file ripgrep-14.1.1-x86_64-unknown-linux-musl/rg
  ripgrep-14.1.1-x86_64-unknown-linux-musl/rg: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped

Re: Stop writing CLI validation. Parse it right the first time

#119

Post by yakshaving_jgt »

jappgar wrote: post #115

I really think parse don't validate gives people a false sense of security (particularly false in dynamic languages like javascript and python). "Well, I already know this is a valid uuid, so I don't really need to worry about sql injection at this point." Sure, this is a dumb thing to do in any case, but I've seen this exact thing happen. Typesafety isn't safety.

Type safety is absolutely some degree of safety. And I don’t know why anyone would think parsing a value into a type that has fewer inhabitants would absolve them of having to prevent SQL injection — these are orthogonal things.

The quote here — which I suspect is a straw man — is such a weird non sequitur. What would logically follow from “I already know this is a valid UUID” is “so I don’t need to worry about this not being a UUID at this point”.

Re: Stop writing CLI validation. Parse it right the first time

#120

Post by mjevans »

metaltyphoon wrote: post #19
parhamn wrote: post #13

> Try to access it and TypeScript yells at you. No runtime validation needed. I was recently thinking about type safety and validation strategies are particularly thorny in languages where the typings are just annotations. E.g. the Typescript/Zod or Python/Pydantic universes. Especially in IO cases where the data doesn't originate in the same type system. In a language like Go (just an example, not endorsing) if you…

> worst case you're getting that struct with all the fields set to zero, and you just have to handle the zero values In the field I work, zero values are valid and doing it in Go would be a nightmare

Database NULL is a valid pattern that any parser SHOULD support and I do consider that a design bug in every parser Go has. Offhand most of them effectively 'update' an object, but make it difficult or impossible to tell if something was __set__ with a value, or merely inherited a default.
Post reply on HN