1

Quick question. I love emacs. I hate typing stuff though, so I like to use e to invoke emacs.

Previously I had my .bash_profile (OS X) configured as: alias e="emacs .". However, I was tired of still having to type emacs {file} when I just wanted to edit one file.

So I tried to whip this up, from some googling, but bash is complaining about the []:

###smart emacs, open file, or if none, dir 
e()
{
    if [$1]; then
        emacs $1
    else
        emacs .
    fi
}

I want to use this to do: e something.c or, just e.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Josh
  • 12,448
  • 10
  • 74
  • 118

2 Answers2

2

Try

if [ $# -ge 1 ]; then
  emacs "$@"

I think bash is very peculiar about spaces. I'm even surprised you're allowed to omit a space between function name and (). (Also, using $@ should open all files you pass.)

ETA: better check against number of arguments, in case of e "" foo.txt...

Ulrich Schwarz
  • 7,598
  • 1
  • 36
  • 48
  • Is that read as, if the number of arguments ($# ?) is greater than, or equal to 1, then open them all? Sorry if this is obvious, I'm quite new to bash functions. – Josh Dec 19 '10 at 17:26
  • @Josh: I was fearing that question... the difference is (I believe) that with $*, e foo bar would open "foo bar" and $@ would open foo and bar, i.e. the splitting into seperate words. A fuller explanation is here: http://tldp.org/LDP/abs/html/internalvariables.html – Ulrich Schwarz Dec 19 '10 at 17:29
  • @Josh: yes, it is. Spaces and quotes in filenames make me avoid touching them wherever possible. – Ulrich Schwarz Dec 19 '10 at 17:30
  • Ah, great! Last-ish question, why the "" around $@? I see that page says you /should/ use them on $@, but you /must/ use them on $* . Why is that? – Josh Dec 19 '10 at 17:33
  • @Ulrich there is no difference between $* and $@ when they are *unquoted.* With double quotes, "$@" is "$1" "$2" ..., while "$*" is expanded as the single argument "$1c$2c..." (where c is the first character of IFS). You almost always want "$@". – SiegeX Dec 19 '10 at 17:34
  • Yes, I should have left those quotes in. Variables without quotes around them tend to go even more horribly wrong when you least expect them to. – Ulrich Schwarz Dec 19 '10 at 17:36
  • @Josh ya, sorry I missed your question about the quotes. if you didn't quote `$1` and you called your function like `e /path/to file with spaces` then `$1` would only be `/path/to` because the internal field separator variable `IFS` will break that path up to 4 parameters: `/path/to`, `file`, `with`, `spaces`. Quoting the variable prevents IFS from performing this *word splitting* operation – SiegeX Dec 19 '10 at 17:44
  • Oh I see! That'd be quite terrible! – Josh Dec 19 '10 at 17:46
1
#!/bin/bash                       

###smart emacs, open file, or if none, dir
e()
{
    if [[ -z "$1" ]]; then # if "$1" is empty
        emacs .
    else
        emacs "$1"
    fi
}
SiegeX
  • 135,741
  • 24
  • 144
  • 154
  • @Josh the single `[` is actually a command, if you type `which [` you'll probably get back a path like `/usr/bin/[`. This is why you need a space after the `[`. The `[[` syntax is an improvement over `[` in that it lets you use logical operators inside such as `&&`, `||`, or `==`. Type `help [` to see more. – SiegeX Dec 19 '10 at 17:27
  • Ah. I'll read up on that! What does the -z flag do? And must the $1 be in ""? I have another set up as py(){ python $1 } and it doesn't seem to complain. – Josh Dec 19 '10 at 17:29
  • @Josh type `help test` to see the list of flags. `-z` checks to see if the parameter in question is `NULL` – SiegeX Dec 19 '10 at 17:36
  • -z is "check if argument is length 0". In this particular case, leaving off the " " might not hurt, but it's not something you should get in the habit of, because the quotes keep filenames with spaces intact. (Think of parameters as textual substitution, not formal parameter passing the way programming languages do.) – Ulrich Schwarz Dec 19 '10 at 17:39