Easy way to run CL

[GoogleCodeExporter]

I wrote small perl script (sorry dont know python) to run googlecl more easily 
and with less typing.

Idea is everytime instead of typing:
    google calender add "Meeting @2PM"
I can simply type:
    gcal a "Meeting @2PM"

So on for other services and tasks.

Attaching the script with this ticket. May be someone can convert it to Python, 
if required.

All you have to do is:
1) Save this file as 'gcli' (same directory as GoogleCL)
2) Create symlinks to it named say:
     gcontact, gcal, gpica etc.

Now you can call:
  gcontact a - means google contact add
  gpica cr - means google picasa create
  gcal ls today - means google calendar today

Also typing just "gcal ls" defaults to "google calendar today"
"gcal list today" also means "google calendar today"

I guess those two should actually be default behaviour anyway. But since its 
not so, I just added those two workarounds.

Hope someone finds it useful

Thank you.

Original issue reported on code.google.com by amis...@gmail.com on 22 Jun 2010 at 9:31

Attachments:

• gcli

[GoogleCodeExporter]

Added support for help task.

Such that:
gcal hlp
gcli cal h
gcli calendar help

all are translated to:
google help calendar

Original comment by amis...@gmail.com on 22 Jun 2010 at 2:00

Attachments:

• gcli

[GoogleCodeExporter]

One proposal to incorporate this is to  break up each service as its own script 
and then have the 'google' script be a generic wrapper that dispatches the rest 
of the command line arguments, with some massaging, to the individual service 
scripts. 

Or do something that you did with creating symlinks as part of the install, but 
then management of updating/changing symlinks would get messy.

Original comment by ericvw on 25 Jun 2010 at 2:25

[GoogleCodeExporter]

1) I am not sure how first proposal will work because then again user will have 
to type long command line. Infact that is how its working currently.

"google" is generic wrapper and based on service argument it calls appropriate 
function.

2) Also creating symlink should not be tough. All you need to do is add 3-4 
lines to setup.py script.

Something similar to this: (in perl)
@services = ("cal", "con", "pic"); #add services here as they are added
system ("cp gcli $BINPATH");
foreach $service (@services) { system ("ln -s gcli $BINPATH/g$service"); }

Original comment by amis...@gmail.com on 25 Jun 2010 at 3:34

[GoogleCodeExporter]

The first proposal avoids having symlinks.  So gcal, gcon, gpic are all there 
own scripts that may be run, but for backwards compatibility, the "google" 
wrapper script will support the existing interface that dispatches out to the 
gcal, gcon, gpic, etc scripts.  

I don't know which way is right if this decides to get accepted and fixed, but 
I was just playing around with some ideas.

Original comment by ericvw on 25 Jun 2010 at 3:48

[GoogleCodeExporter]

Oh ok that way. Well in that case code will increase unnecessarily. Instead of 
5 symlink creation, they will have to maintain 5 scripts.

In my case gcli script (that I wrote in perl) can be completely eliminated if 
current "google" script is made smart enough and runs services based on the 
name it has been called as. i.e. if its called as gcal then service wud be 
calendar. If its called as google then service wud be the next argument.

Original comment by amis...@gmail.com on 25 Jun 2010 at 3:56

[GoogleCodeExporter]

Well if you are at a console in linux just put these in as a alias':

alias gcal="google calendar"
alias gcala="gcal add"
alias gcall="gcal list"
alias gcon="google contacts"
alias gcona="gcon add"
alias gconl="gcon list"

Seems pretty easy to me.

Thanks,
SoBBie

Original comment by paul.kso...@gmail.com on 26 Aug 2010 at 5:31

[GoogleCodeExporter]

Yes that should work too.

But argument short forms like a for add, ls for list would not work.

Also "gcal a" is more intuitive than "gcala", as in "service task"

And everytime GoogleCL adds new services, alias will have to be added, but if 
such feature is integrated in package itself, it wud be even better.

Also aliases may not work in scripts.

Thanks,
Amish.

Original comment by amis...@gmail.com on 27 Aug 2010 at 2:17

[GoogleCodeExporter]

I think a package-incorporated typing speed-up would come from tab completion. 
This suggestion has merit, but I'd prefer to install it as a side package, not 
include it in the default distribution.

Let me know if anything like this gets created, and we'll link it in the 
RelatedWorks wiki page!

Original comment by tom.h.mi...@gmail.com on 5 Oct 2010 at 4:15

• Changed state: WontFix
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect