Skip to main content

cd under development packages nested folders without repeating yourself

To me Plone development environment means Fedora 12, terminator and vim. As I do lots of development in the shell there has been one annoying little thing which I'm tired of - cd:ing under development packages inner structure to where the actual code lives.


Doesn't seem much but if you repeat that many times a day you'll get tired of it. Of course you can always launch vim for the package root and open the file you wanted from there, but it's still extra effort.

Few weeks ago me and my colleague Jussi Talaskivi started to think that there has to be a script which takes you to your destination simply by parsing dotted name and using information from there to cd you to the correct place. After spending some time googling around we found none. Annoyed by this we decided to do this missing script by ourself.

Soon it turned out that this wasn't that easy task as it sounds - simple shell or python script where you just parse correct path from arguments wouldn't do the trick as they're launched in a separate process which doesn't have any effect on the working dir of your shell. Little research and try - error approach later we found working solution.

1. Create shell script (eg. pcd.sh) to somewhere on your $PATH which contains following lines:

#!/bin/sh
cd `echo -n $1/;echo $1 | sed -e 's/\./\//g'`


2. Chmod your shell script so that you can execute it.

3. Edit your .bashrc and add following alias:

alias pcd=". pcd.sh"


Now pcd command should work as expected:

$ pwd
/home/jutaojan/workspace/
$ pcd very.long.packagename
$ pwd
/home/jutaojan/workspace/very.long.packagename/very/long/packagename


Excellent!

The key element is the first dot in the alias. This makes your command to execute in the current shell session. As alias doesn't cope with arguments you'll need a script (in this case pcd.sh) for parsing to work. I know this isn't the most sophisticated piece of code and there probably are better ways to achieve the same result, but I couldn't find one.

I hope this example is useful for someone frustrated for the long nested structures we're all so familiar with.
Labels:

Comments

  1. davidjbApril 11, 2011 at 2:29 AM

    Really nice idea.

    As for the the bash alias, you can implement this with a function call in your .bashrc :

    function pcd() {
    cd `echo -n $1/;echo $1 | sed -e 's/\./\//g'`
    }

    and that accepts arguments.

    ReplyDelete
  2. csengerApril 11, 2011 at 11:49 AM

    Thanks Jukka for the idea and davidjb for the comment.
    I expanded it a bit to support packages with a 'src' directory inside.

    function pcd()
    {

    PACKAGENAME=$1
    cd $PACKAGENAME
    if [ -d "src" ]
    then
    cd "src"
    fi
    cd `echo $PACKAGENAME | sed -e 's/\./\//g'`
    }

    ReplyDelete
  3. UnknownApril 11, 2011 at 9:24 PM

    Davidjb, thanks! Function call in shell is for sure the missing more sophisticated solution.

    Csenger, thank you also for the important addition! I think this script is near reaching the perfection in here :)

    ReplyDelete
  4. EsaApril 15, 2011 at 1:45 AM

    Btw, Command-T is a great Vim plugin for opening files in deep directory structures:

    https://wincent.com/products/command-t

    ReplyDelete
  5. Wouter Vanden HoveMarch 18, 2012 at 1:26 AM

    Take a look at autojump, IMHO beats everything above.
    https://github.com/joelthelion/autojump

    Example session:

    > pwd
    /home/wouter

    > j panel
    > pwd
    /opt/zope/plone-coredev-4.2/src/plone.app.controlpanel/plone/app/controlpanel

    ReplyDelete

Post a Comment

Popular posts from this blog

Usability and Plone

I've seen in here and there someone mentioning that usability of Plone is very good. Lot's of people - me included - like the fact that in Plone you don't have separate content management interface compared to some of Plones rivals. That counts for something when we're talking about good usability. Still that is only one quite small part of the whole picture. So what else is there? What do people like in Plone and where are the rough edges for end users? If general consensus is that Plone does have good usability, where is the actual proof of that? On plone.org I found one page in developer documentation mentioning following:  "Plone differentiates itself on usability. The intuitiveness of the user interface is what attracts people to Plone the most." I interpret this sentence meaning about the "one view for all" approach. What bugs me in this is that this whole sentence about good usability is about how the UI works compared to Plones competi...
4 comments
Read more

Speed comparsions between Plone and Wordpress

Jon Stahl wrote recently a blogpost about Plone being three times faster than Dropal, Joomla and Wordpress . We had a small discussion about this in my workplace and as my colleague pointed out this wasn't a really that comprehensive test that you could state Plone being 3 times faster than it's competitors. This seemed a bit unfair test considering how fast this has been spread in tweet/blogosphere, so I decided to repeat the test with a bit more critical viewpoint. What's wrong in the original test? No one would consider opinion poll with 10 answers nowhere near trustworthy - it's all the same with requests. I didn't want to put up all the cms so I just set up second best (Wordpress 2.9.1) and compared that to my Plone development site (4.0a3). As a comparsion I did the first test with same ab command Jon used and my iMac gave following results: Wordpress: 7.13 requests / second Plone: 17.10 requests / second So far we have clear winner and Jons data hol...
7 comments
Read more

Plone 4, ZEO and supervisor

This post belongs also to the "lessons learned" category. With Plone 3, ZEO and supervisor combination you've probably configured your supervisor to start plone instances by running $BUILDOUT/parts/client1/bin/runzope. Problem is that with Plone 4 your $BUILDOUT/parts/client folder doesn't contain anything else than etc folder. You know starting instances by targeting supervisor to use $BUILDOUT/bin/client1 fg doesn't work like you'd expect (supervisor would control the client1 script - not the actual plone process). My colleague Jussi Talaskivi figured that using 'console' argument instead of 'fg' for bin/client1 script should do the trick. With 'console' argument stopping, starting and restarting Plone 4 instances with supervisor works like a charm. Below is full example of working supervisor configuration. [buildout] parts = supervisor [supervisor] recipe = collective.recipe.supervisor port = 8200 user = xxxx password = ...
5 comments
Read more