Feature - Rejected The "send" syntax

[Raijinili]

This is a request for comment more than a request to change something. I understand that there's a lot of code that may rely on the syntax being a certain way, and I'm not really sure what to do about that (I mean, you COULD use more symbols, but...). I'm also aware that this may not be a thing that people would agree needs to be changed.

Currently, we use send like this:
csend <stuff> to <user>

However, you first think of the person to send it to, rather than what to send. It seems, then, logical to have it the other way.

 

[Veracity]

That may-or-may-not be more "logical" - but I guarantee that we are not going to change it after 5 years of having it the current way.

 

[slyz]

"send someone to something" ?

 

[lostcalpolydude]

I think he wanted "send someone something" which would be fun to parse when someone's name has a space in it and the last part of their name is an item name.

 

[Veracity]

"send someone the-following-stuff item1, item2, ..."

Item names can have spaces and fuzzy matching. We already have the facility to parse lists of them in commands. The "to" word in the csend command separates the item list from the user name. A reversed syntax would need a similarly distinguished token - which couldn't be part of a valid user name.

I imagine it could be done, but I stand by my belief that it's not worth the coding, testing, and howls of rage from people who have to change their scripts. And since it is a CLI command, if they are calling cli_execute from ASH to do it, the script will not suddenly fail validation. It will simply fail to work correctly when it hits the command.

 

[Raijinili]

send to <username>: <list> || message
send to <username> : <list> || message

Or (while it's probably easily aliased ), a sendto command.

 

[Theraze]

As Veracity said... it would break existing functionality without providing any real benefit you can't accomplish by (as you said, a very easily) aliased command.