[borracciaBlu]

Sorry you right, the "Why?" section it could be better about the difference with an alias.

So, if you are working alone an alias is perfectly fine. If you are disciplined you could use a convention like `upload_blog_dev`, `upload_blog_stag`, `upload_blog_prod` and everything should be more or less fine.

I say more or less fine because if you are editing an alias 3 lines long you may have some typos or configuration issue (I'll talk later about that) and it can be far away from to immediate to detect the bug, edit the aliases file or the (.bashrc|.zshrc) file and reload the shell.

With aws-upload and tmux, I edit the settings in one panel and test in the other. Real time, no reload.

Which kind of issue can you face with this kind of task?

From my experience, I would say at least 3.

- the folder you are trying to upload doesn't exist (wrong path),

- the pem file you specify doesn't exist (wrong path)

- the pem file exists but it has wrong permissions.

Alias doesn't give you any support to debug these issues, aws-upload has the cmd `check` to do that.

The thing can start to be more tricky if you have a colleague that need the alias for him/her and potentially has exactly to edit these values in the alias.

In this case what you have to do is open the alias file, find the row with the alias you want and send it. In aws-upload you have the setting file in ~/.aws-upload . You send it.

Think that, if you to have a lot of aliases the alias file can start to grow exponentially, and of course, the possibility of mistakes and losing time grows as well.

Instead aws-upload reduce for you the scope of the critical information you have to manage and it tries to support you during the process.

Useful cmd in these situations:

- aws-upload check key // it check folder, pem file and permission

- aws-upload new key // create new setting files

- aws-upload cp oldKey newKey // copy a setting file

- aws-upload edit key // edit setting files

I hope it makes a little bit more sense now.