Hacker News Reader

Comment by OJFord | Hacker News Reader

Why:

    aws cloudcontrol delete-resource \
     --type-name AWS::Lambda::Function \
     --identifier ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9

and not:

    aws cloudcontrol delete-resource \
     AWS::Lambda::Function \
     ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9

(and why 'cloudcontrol' for that matter, not top-level CRUD)

Awscli loves its arguments. Several people are going to point me at autocompletions, tell me zsh has this really great feature where .. all fine. But why have this 'problem' to solve in the first place? I don't get it.

For non-interactive use, sure, I don't care how verbose it is, it's even a sort of self-documenting feature. Is that it? They just really want all interaction via the web console?

View on HN

All AWS CLI commands follow the format 'aws [service] [action] [flags...]'. To my knowledge, there are exactly zero instances where positional arguments are used outside of naming the service and action; its always flags.

Whether this is best or not is a different discussion; I'm simply pointing out the irony of suggesting the CLI API for a service designed to make their APIs more consistent, should be inconsistent with the other CLI APIs customers are used to.

Yes I know, I was sort of using it (new CLI designed to be a better interface) to say why is it so.

Apparently I hold a minority opinion that's so offensively contrary it deserves downvotes though!

I maybe didn't make it clear enough, but I think it's somewhere between 'don't care either way' and 'great' for non-interactive/scripted use. I just don't like the UX at all for using it interactively, I find it extremely slow and cumbersome.

This looks to be a big improvement, but - to me - just leaves such easy obvious trivial stuff on the table.

Re: positional arguments, I was surprised recently to find this one (`outfile`) in the AppConfig API.

https://awscli.amazonaws.com/v2/documentation/api/latest/ref...

The AWS CLI is old and for the most part auto-generated from the API definitions. I actually prefer the first example to the second one, but in general I’m happy that it’s consistent. Even if it’s sometimes consistently annoying (help, not —help).

Other than the flag name, what's other significance of this difference? The flag seems trivial to me. Warp it in a shell script seems sufficient.

What do you mean other than? I removed it, that is the (entire) difference.

> Warp it in a shell script

As I said, for non-interactive use of course I don't care. But trying to actually do/check/test anything with awscli interactively/'manually' is pretty painful IMO.

I disagree here. The first example is much more self-describing and follows the same paradigm that the rest of the AWS CLI already follows. I'd prefer erbosity here rather than the AWS CLI trying to figure out what I'm doing.

I'm of the same opinion - I'd rather not have to consider the argument order, and instead just be able to append flags to an interactive command in any order I see fit as I'm refining queries.

And you no longer have to worry about the meanings of positional arguments changing between versions and potentially running the wrong command.

jeez write your own wrapper script then. I don't understand what this needs to be bikeshedded for.

That is a solved issue . It is the standard way of command line syntax and provides a common way of parsing command line for many OS. You can certainly do things “another” way but all it will do is break decades worth of work for standardization and good old fashioned common sense. Make things modular so you can expand in different ways.

Well that's not really true, or at least incomplete. GNU & BSD have different styles; I believe both do positional/unnamed arguments.

It's true that awscli goes for all --named=args currently, but that's not decades of it not happening in general, and I just commented on wishing it weren't the case here.

I think this is a great simplification/abstraction, and I don't see why it couldn't go further and just be `aws <crud> <type> <resource>`. But that's apparently highly disagreeable even as a mere thought or suggestion, so I'll shutup.

Such verbosity (and other bloat and complexity in how AWS does things) is why I could never get excited about S3, EC2 et seq. when these services were first announced. Rightly or wrongly, I believe it is because most of AWS was originally implemented in Java. Programming in Java requires a certain comfort with verbosity and clunkiness. That showed through in early AWS interfaces and documentation. Indeed, it has alway been painful to interact with manually.

Whatever language is used, there is a choice of either positional or named arguments.

Consistently using named arguments for a CLI to an API seems to be a good idea. Nothing to do with whether the API is written in Java.

All of the AWS CLI support input in JSON or YAML as well and will generate the skeleton of the call for you as well.

Reply on news.ycombinator.com