xs - A less bad shell

syfe · 2009-12-26 03:50:19

Justification

One of the best shells out there is bash. But bash has to stay compatible with
ancient shells from long ago and many of their strange quirks.

The most obvious example is that:

if $dothis; then
    $dostuff
fi

is valid syntax - however, the one-line version

if $dothis; then; $dostuff; fi

gives the wonderful error

bash: syntax error near unexpected token `;'

While this example may seem trivial, once you start writing serious
shell scripts, you may find yourself running into these tyeps of confusing
errors all the time (or you may never have that problem, depending on your luck,
but I got very frustrated with it).

These types of problems plague all sh-compatible shells (ksh, pdksh, etc.), and similar
problems exist for all csh-derived shells (tcsh). Fortunately these are not the only families
of shells.

History

Xs actually owes most of its work to the developers of two previous shells,
rc and es. Rc was intended to be a shell like sh that didn't suck so much - es
continued it's work with a little influence from functional programming languages.
However, es stopped being developed a long time ago, so xs is here to pick
up the slack, with several small, but significant improvements.

A brief preview

Xs eschews the weird while; do; done and if; then; fi
syntax for a more C-like one:

if {$condition} {
$dostuff
} else if {$condition2} {
$domore
}

Functions can be defined with a fairly logical syntax compmared to bash:

fn useless_function arg1 otherargs {
    echo 'Arg1: ' $arg1 'Some other stuff: ' $otherargs
}

Some other things to note are that all variables are lists (so it
is immediately clear how a variable is expanded, no ugly tricks like "$arg" needed
to avoid whitespace issues), lexical closures and anonymous functions are provided,
arithmetic expansions, non-linear pipes, and more.
Just skim the manual to see, I don't want to cover very much here.

AUR (thanks mostly to milomouse): http://aur.archlinux.org/packages.php?ID=34637

Manual build:

You can get xs from git at git://github.com/frytvm/XS.git.
It depends on the boehm gc and boost library.
Full build instructions:

git clone git://github.com/frytvm/XS.git
cd XS
autoreconf
./configure
make
sudo make install

*Edit1: Add boost library to deps (oops).

Last edited by syfe (2010-02-15 02:07:43)

livibetter · 2009-12-26 04:03:07

syfe wrote:

Justification
The most obvious example is that:
if $dothis; then
    $dostuff
fi
is valid syntax - however, the one-line version
if $dothis; then; $dostuff; fi
gives the wonderful error
bash: syntax error near unexpected token `;'

This should be

if $dothis; then $dostuff; fi

No semi-colon after `then`
But I might use

$dothis && $dostuff

Still thanks for this xs shell information.

syfe · 2009-12-26 04:49:55

Yeah, but normally you expect ;=newline in shell, so you get my example, which fails even though it "seems" right.

JohannesSM64 · 2009-12-26 05:31:04

Interesting concept. How do you handle tests (like zsh's double-brackets)?

Would try, but:

print.cxx:250:22: error: #if with no expression
print.cxx: In function 'int fmtprint(Format*, const char*, ...)':
print.cxx:255: error: array must be initialized with a brace-enclosed initializer
print.cxx:262: error: invalid array assignment
make[1]: *** [print.o] Error 1
make[1]: Leaving directory `/home/johannes/Source/XS'
make: *** [all] Error 2

Btw, your first complaint is bash retardedness.. zsh doesn't have that "feature"

Last edited by JohannesSM64 (2009-12-26 05:36:50)

Shapeshifter · 2009-12-26 11:38:58

syfe wrote:

if {$condition} {
$dostuff
} else if {$condition2} {
$domore
}

Oh, oh... Oh no... that is - I'm sorry to say - horrible, in my opinion. So many braces! If your argument is nonsensical syntax in one-liner bash scripts, why not improve the syntax. I mean, I could even simply dream up "python-like" syntax for the same thing. But adding this much synatx just to evade ambiguity is total overkill and far from modern.

if condition: command1; command2; else: command3;

Just my opinion.

Last edited by Shapeshifter (2009-12-26 11:39:17)

ArchArael · 2009-12-26 12:04:10

I agree that the syntax could be simpler.

Did you ever tried fish shell?

Maybe you could borrow some concepts from it or fork it. The main developer seems to have stop developing it.

JohannesSM64 · 2009-12-28 00:54:15

Yeah, I agree, braces suck. I like Shapeshifter's suggestion.
Some tips:

- To assign variables, use var = foo
- var=foo should have no special meaning, and be regarded as a command name
- Maybe replace $var for something more sensical - if you want to expand a variable inside a word in existing shells, wo$varrd will be regarded as $varrd, so you have to use wo${var}rd. I actually find Windows' %var% to be more robust.
- For string comparisons, to prevent %var% == %foo% and %var% != %foo% from misbehaving if either is empty: error out if ever attempting to use an empty variable, and to replace [[ -z $var ]], have a special function to check if a variable is empty.
- And avoid redundant shortcuts and several names for things - examples: in zsh, $[] and $(()) mean the same thing, and there are 3 forms of for - only one is needed.

Last edited by JohannesSM64 (2009-12-28 01:16:30)

JohannesSM64 · 2009-12-28 08:22:15

Syntax idea:

for foo in `cmd1`:
  cmd2 %foo%
end

if condition:
  cmd1
elif condition2:
  cmd2
else:
  cmd3
end

case %bar% in
  one: foo
  two: foo
  three: foo
end

All can be done in one line:

for foo in `cmd1`: cmd2 %foo%; end; if condition: cmd1; elif condition2: cmd2; else: cmd3; end; case %bar% in one: foo; two: foo; three: foo; end

</brainstorm>

Last edited by JohannesSM64 (2009-12-28 08:26:49)

syfe · 2009-12-29 04:38:55

Here's a response to a few issues

BRACES

Well, part of the reason that xs uses braces (at least right now, it's mostly inherited from es) is for the same reason that ruby uses it - "blocks" are top level objects.
This allows a lot of xs to be written in xs itself (switch, if/else and the like are implemented in xs) and is supposed to give the user more power to write custom functions, (xs's small self-test suite also takes advantage of this, it's actually pretty cool). This is also kind-of similar to tcl in this aspect.
I do admit, however, that sometimes there are a lot of braces and it could potentially be improved, maybe with a more python/ruby-ish syntax built-in too, like you guys are suggesting.

ASSIGNMENT WITH = (Johannes)

The reason almost no shell does what you suggest is that it makes the parsing really messed up, since = is also used in, e.g. dd if=blah.iso or ls --color=yes. Es supported this, but you had to escape the = (dd if\=blah.iso), which is just plain horrible. That's why I went with (in my mind) the second best option, var := value.

Some random other stuff:
* Xs has a built-in testing operator "~" which is usually preferred over test (also, [test] syntax is not currently supported)
* Variable is empty test (Johannes) - xs already solves this problem; all variables are lists (this turns out to be a really great idea in lots of ways), so empty variables equal the empty list. Failing on undefined variable might be a good idea (though it also breaks the list := foo $list paradigm and similar)
* I hopefully fixed the build error Johannes was having (although it's a very strange error and i thought that it would never be triggered on a modern compiler...wierdness....)

As far as other shells:
* fish has some good ideas, although I feel it lacks power of xs scripting-wise. (it's also not dead as far as i can tell)
* zsh arguably suffers from lot of feature-creep and supporting a lot of syntaxes which is really more confusing than helpful.

JohannesSM64 · 2009-12-29 05:26:28

syfe wrote:

* zsh arguably suffers from lot of feature-creep and supporting a lot of syntaxes which is really more confusing than helpful.

Yeah. It's obviously to make users switching from a range of shells feel at home, but it's annoying for a new user.

syfe wrote:

The reason almost no shell does what you suggest is that it makes the parsing really messed up, since = is also used in, e.g. dd if=blah.iso or ls --color=yes. Es supported this, but you had to escape the = (dd if\=blah.iso), which is just plain horrible. That's why I went with (in my mind) the second best option, var := value.

Really? What I meant is to make var = value assign a variable, but not var=value. Thus, dd if=blah.iso would still work..

JohannesSM64 · 2009-12-29 05:32:41

% make
/bin/sh ./ylwrap parse.yxx y.tab.c parse.cxx y.tab.h parse.h y.output parse.output -- bison -y  -d
updating parse.h
make  all-am
make[1]: Entering directory `/home/Johannes/Source/XS'
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT access.o -MD -MP -MF .deps/access.Tpo -c -o access.o access.cxx
In file included from es.hxx:6,
                 from access.cxx:6:
stdenv.hxx:22:29: error: boost/foreach.hpp: No such file or directory
In file included from stdenv.hxx:10,
                 from es.hxx:6,
                 from access.cxx:6:
/usr/include/gc/gc_cpp.h:183: error: extra qualification 'gc::' on member 'operator delete []'
In file included from access.cxx:6:
es.hxx:269: error: 'string' is not a member of 'std'
es.hxx:269: error: 'string' is not a member of 'std'
es.hxx:270: error: 'string' is not a member of 'std'
es.hxx:270: error: 'string' is not a member of 'std'
es.hxx:270: error: template argument 1 is invalid
es.hxx:271: error: 'string' is not a member of 'std'
es.hxx:271: error: 'string' is not a member of 'std'
es.hxx:271: error: template argument 1 is invalid
es.hxx:271: error: template argument 1 is invalid
es.hxx:271: error: template argument 1 is invalid
es.hxx:271: error: template argument 3 is invalid
es.hxx:271: error: template argument 4 is invalid
es.hxx:272: error: invalid type in declaration before ';' token
es.hxx:273: error: expected class-name before ',' token
es.hxx:277: error: declaration of 'operator[]' as non-function
es.hxx:277: error: expected ';' before '(' token
In file included from /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/ostream_insert.h:41,
                 from /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/string:51,
                 from prim.hxx:2,
                 from access.cxx:7:
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/cxxabi-forced.h:34: error: expected `;' before end of line
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/cxxabi-forced.h:34: error: expected `}' before end of line
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/cxxabi-forced.h:34: error: expected unqualified-id before end of line
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/cxxabi-forced.h:34: error: expected declaration before end of line
make[1]: *** [access.o] Error 1
make[1]: Leaving directory `/home/Johannes/Source/XS'
make: *** [all] Error 2

I'm using Cygwin atm, could that be the problem? My first build attempt (posted 3 days ago) was in Arch btw.

Or am I missing anything?

Last edited by JohannesSM64 (2009-12-29 05:33:56)

ArchArael · 2009-12-29 08:21:58

syfe wrote:

* fish has some good ideas, although I feel it lacks power of xs scripting-wise. (it's also not dead as far as i can tell)

I hope you're right. I'm trying to fix a bug myself but it occurs randomly and is difficult to replicate it.

Is the xs shell meant to be more a scripting environment rather than interactive one? I'm more interested in the interactive shells that's why I'm fascinated with fish shell. I think that for scripting purposes there are many choices but for good interactive use there are only few choices. Fish IMHO is the best interactive shell I ever used that's why I'm asking you about xs' interactive nature.

"~" symbol is used as /home/user folder alias in almost all shells around, does in xs "~" symbol is only the testing operator or it can also be used as home directory alias itself?

Last edited by ArchArael (2009-12-29 08:30:34)

litemotiv · 2009-12-29 10:32:45

syfe wrote:

Here's a response to a few issues
BRACES
Well, part of the reason that xs uses braces (at least right now, it's mostly inherited from es) is for the same reason that ruby uses it - "blocks" are top level objects.
This allows a lot of xs to be written in xs itself (switch, if/else and the like are implemented in xs) and is supposed to give the user more power to write custom functions, (xs's small self-test suite also takes advantage of this, it's actually pretty cool). This is also kind-of similar to tcl in this aspect.
I do admit, however, that sometimes there are a lot of braces and it could potentially be improved, maybe with a more python/ruby-ish syntax built-in too, like you guys are suggesting.

i think adopting some C-syntax is a nice for a shell, and you only need to avoid ambiguity as shapeshifter points out.

what's wrong with:

if ($condition) {
  $dostuff
} else if ($condition2) {
  $domore
}

$var = ($condition) ? value1 : value2

?

JohannesSM64 · 2009-12-29 22:27:40

litemotiv wrote:

$var = ($condition) ? value1 : value2

I find make || return 1 to be more convenient than if (!make) {return 1} or make ? no-action : return 1

Last edited by JohannesSM64 (2009-12-29 22:32:53)

litemotiv · 2009-12-29 22:47:29

JohannesSM64 wrote:

I find make || return 1 to be more convenient than if (!make) {return 1} or make ? no-action : return 1

i agree, i meant for simple assignments:

$status = ($temperature < $threshold) ? 'green' : 'red'

syfe · 2009-12-29 23:38:03

@ArchAreal
~ is a built-in command (like test is in bash); it doesn't affect ~/ being home (that still works as normal).

Xs is meant to serve as both an interactive and scripting shell.
Admittedly, it doesn't have some of the cool features of fish's interface - no syntax-coloring, for example. (actually, it's ui
acts a lot like bash because they both use readline).

@Johannes (=)
Actually, I think I slightly misred your idea. I think your idea actually _is_ implementable, my bad. Actually, it's not a bad idea, either....

As far as your build, for one thing you are missing boost library, which xs uses parts of (I think you can install it with cygwin, though).
There also might be some other minor issues due to lack of testing on other platforms.

@litemotiv
Part of the reason for the braces in if-conditions is that
the test is really just the result of running a command (like test),
so it's consistent with the other uses of braces.

As far as ternary-operator wise, that makes both "?" and ":" reserved-words, meaning
you would have to, for example, write http\://blah or 'http://blah' to avoid getting a syntax error.

Not that the current xs-stuff is perfect, here is that code right now in normal xs:

status := <={ if {test $temperature -lt $threshold} {result green} {result red} }

However, this can be improved a little without changing the language;
you can easily write an if-expr* function easily that lets you do:

status := <={ if-expr {test $temperature -lt $threshold} green red }

Which is a little less bad, and doesn't need new syntax.

*if-expr would be:

fn if-expr cond then else {
  if $cond {result $then} {result $else}
}

Last edited by syfe (2009-12-30 00:39:25)

JohannesSM64 · 2009-12-30 00:39:46

% find /usr/lib|grep boost
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/boost_concept_check.h
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/boost_concept_check.h
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/boost_sp_shared_count.h
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/tr1/boost_sp_shared_count.h
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/tr1_impl/boost_shared_ptr.h
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/tr1_impl/boost_sp_counted_base.h
/usr/lib/gcc/i686-pc-mingw32/3.4.4/include/c++/bits/boost_concept_check.h
/usr/lib/libboost_date_time-gcc-mt-1_33_1.a
/usr/lib/libboost_date_time-gcc-mt-s-1_33_1.a
/usr/lib/libboost_date_time-gcc-mt-s.a
/usr/lib/libboost_date_time-gcc-mt.a
/usr/lib/libboost_filesystem-gcc-mt-1_33_1.a
/usr/lib/libboost_filesystem-gcc-mt-s-1_33_1.a
/usr/lib/libboost_filesystem-gcc-mt-s.a
/usr/lib/libboost_filesystem-gcc-mt.a
/usr/lib/libboost_iostreams-gcc-mt-1_33_1.a
/usr/lib/libboost_iostreams-gcc-mt-s-1_33_1.a
/usr/lib/libboost_iostreams-gcc-mt-s.a
/usr/lib/libboost_iostreams-gcc-mt.a
/usr/lib/libboost_prg_exec_monitor-gcc-mt-1_33_1.a
/usr/lib/libboost_prg_exec_monitor-gcc-mt-s-1_33_1.a
/usr/lib/libboost_prg_exec_monitor-gcc-mt-s.a
/usr/lib/libboost_prg_exec_monitor-gcc-mt.a
/usr/lib/libboost_program_options-gcc-mt-1_33_1.a
/usr/lib/libboost_program_options-gcc-mt-s-1_33_1.a
/usr/lib/libboost_program_options-gcc-mt-s.a
/usr/lib/libboost_program_options-gcc-mt.a
/usr/lib/libboost_python-gcc-mt-1_33_1.a
/usr/lib/libboost_python-gcc-mt.a
/usr/lib/libboost_regex-gcc-mt-1_33_1.a
/usr/lib/libboost_regex-gcc-mt-s-1_33_1.a
/usr/lib/libboost_regex-gcc-mt-s.a
/usr/lib/libboost_regex-gcc-mt.a
/usr/lib/libboost_serialization-gcc-mt-1_33_1.a
/usr/lib/libboost_serialization-gcc-mt-s-1_33_1.a
/usr/lib/libboost_serialization-gcc-mt-s.a
/usr/lib/libboost_serialization-gcc-mt.a
/usr/lib/libboost_signals-gcc-mt-1_33_1.a
/usr/lib/libboost_signals-gcc-mt-s-1_33_1.a
/usr/lib/libboost_signals-gcc-mt-s.a
/usr/lib/libboost_signals-gcc-mt.a
/usr/lib/libboost_test_exec_monitor-gcc-mt-1_33_1.a
/usr/lib/libboost_test_exec_monitor-gcc-mt-s-1_33_1.a
/usr/lib/libboost_test_exec_monitor-gcc-mt-s.a
/usr/lib/libboost_test_exec_monitor-gcc-mt.a
/usr/lib/libboost_thread-gcc-mt-1_33_1.a
/usr/lib/libboost_thread-gcc-mt-s-1_33_1.a
/usr/lib/libboost_thread-gcc-mt-s.a
/usr/lib/libboost_thread-gcc-mt.a
/usr/lib/libboost_unit_test_framework-gcc-mt-1_33_1.a
/usr/lib/libboost_unit_test_framework-gcc-mt-s-1_33_1.a
/usr/lib/libboost_unit_test_framework-gcc-mt-s.a
/usr/lib/libboost_unit_test_framework-gcc-mt.a
/usr/lib/libboost_wave-gcc-mt-1_33_1.a
/usr/lib/libboost_wave-gcc-mt-s-1_33_1.a
/usr/lib/libboost_wave-gcc-mt-s.a
/usr/lib/libboost_wave-gcc-mt.a

I have everything in Cygwin's "devel" and "libs" installed, including boost, boost-devel and libboost.

Last edited by JohannesSM64 (2009-12-30 00:44:39)

syfe · 2009-12-30 01:12:13

Oh sorry, it seems from your command output that you only have boost 1.33.1.
Sadly, xs uses a small feature which was introduced in 1.34.
According to google, cygwin's boost is unmaintained right now,
so if you want to compile xs you may have to download a less ancient boost yourself.

JohannesSM64 · 2010-01-05 13:12:27

Back on Arch:

~/Source/XS make
/bin/sh ./ylwrap parse.yxx y.tab.c parse.cxx y.tab.h parse.h y.output parse.output -- bison -y  -d
updating parse.h
make  all-am
make[1]: Entering directory `/home/johannes/Source/XS'
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT access.o -MD -MP -MF .deps/access.Tpo -c -o access.o access.cxx
mv -f .deps/access.Tpo .deps/access.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT closure.o -MD -MP -MF .deps/closure.Tpo -c -o closure.o closure.cxx
mv -f .deps/closure.Tpo .deps/closure.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT conv.o -MD -MP -MF .deps/conv.Tpo -c -o conv.o conv.cxx
mv -f .deps/conv.Tpo .deps/conv.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT eval.o -MD -MP -MF .deps/eval.Tpo -c -o eval.o eval.cxx
mv -f .deps/eval.Tpo .deps/eval.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT fd.o -MD -MP -MF .deps/fd.Tpo -c -o fd.o fd.cxx
mv -f .deps/fd.Tpo .deps/fd.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o glob.cxx
mv -f .deps/glob.Tpo .deps/glob.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT glom.o -MD -MP -MF .deps/glom.Tpo -c -o glom.o glom.cxx
mv -f .deps/glom.Tpo .deps/glom.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT input.o -MD -MP -MF .deps/input.Tpo -c -o input.o input.cxx
mv -f .deps/input.Tpo .deps/input.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT heredoc.o -MD -MP -MF .deps/heredoc.Tpo -c -o heredoc.o heredoc.cxx
mv -f .deps/heredoc.Tpo .deps/heredoc.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT list.o -MD -MP -MF .deps/list.Tpo -c -o list.o list.cxx
mv -f .deps/list.Tpo .deps/list.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT match.o -MD -MP -MF .deps/match.Tpo -c -o match.o match.cxx
mv -f .deps/match.Tpo .deps/match.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT opt.o -MD -MP -MF .deps/opt.Tpo -c -o opt.o opt.cxx
mv -f .deps/opt.Tpo .deps/opt.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT prim-ctl.o -MD -MP -MF .deps/prim-ctl.Tpo -c -o prim-ctl.o prim-ctl.cxx
mv -f .deps/prim-ctl.Tpo .deps/prim-ctl.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT prim-etc.o -MD -MP -MF .deps/prim-etc.Tpo -c -o prim-etc.o prim-etc.cxx
mv -f .deps/prim-etc.Tpo .deps/prim-etc.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT prim-io.o -MD -MP -MF .deps/prim-io.Tpo -c -o prim-io.o prim-io.cxx
mv -f .deps/prim-io.Tpo .deps/prim-io.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT prim-sys.o -MD -MP -MF .deps/prim-sys.Tpo -c -o prim-sys.o prim-sys.cxx
mv -f .deps/prim-sys.Tpo .deps/prim-sys.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT prim.o -MD -MP -MF .deps/prim.Tpo -c -o prim.o prim.cxx
mv -f .deps/prim.Tpo .deps/prim.Po
g++ -DHAVE_CONFIG_H -I.     -g -O2 -MT print.o -MD -MP -MF .deps/print.Tpo -c -o print.o print.cxx
print.cxx: In function 'int fmtprint(Format*, const char*, ...)':
print.cxx:262: error: invalid array assignment
make[1]: *** [print.o] Error 1
make[1]: Leaving directory `/home/johannes/Source/XS'
make: *** [all] Error 2

syfe · 2010-01-05 23:26:11

Hi, thanks for all the testing.
I think I fixed all the errors like that (turns out there is a more portable way to write that type of code than I had, oops).
Also, I have tried changing the assignment operator to your suggestion in the master branch, so if you can get it to build, you can try that out too

JohannesSM64 · 2010-01-06 17:50:14

Works now, feedback in a bit

Last edited by JohannesSM64 (2010-01-06 17:50:47)

JohannesSM64 · 2010-01-07 13:44:20

Found a bug:

; alias ls 'pwd'
; ls
/home/johannes
; alias ls 'ls --color'
ls --color: No such file or directory

syfe · 2010-01-08 00:40:54

That's actually not a bug (except maybe in the documentation).
The way you do it is:
alias ls ls --color

You _don't_ use the quotes because "ls" and "--color" are seperate arguments.
That said, maybe I should pick a different name to avoid confusing users from bash, etc. (in fact, xs's alias works almost completely differently internally from bash's alias, though it provides a similar function)

milomouse · 2010-02-11 23:53:35

Hello syfe. I just started testing out the shell today and am pleasantly pleased. Thanks for this contribution, I hope it's development continues. I'll post again later if I have any concerns/problems/requests.

P.S. I tried to email you but your email is private, and I'm not sure if anyone else cares but here's a PKGBUILD I whipped up for my own install (as I don't see it in the AUR yet, unless I missed it somehow). You can change the name from xs-git to xs and/or anything else you want-- just sharing my pkgbuild. http://github.com/milomouse/pkgbuilds/b … s/PKGBUILD

syfe · 2010-02-15 02:06:36

Thanks a lot, i put up your pkgbuild with a few minor edits as xs-git on AUR.
I'm glad to hear you like it so far

Arch Linux

#1 2009-12-26 03:50:19

xs - A less bad shell

#2 2009-12-26 04:03:07

Re: xs - A less bad shell

#3 2009-12-26 04:49:55

Re: xs - A less bad shell

#4 2009-12-26 05:31:04

Re: xs - A less bad shell

#5 2009-12-26 11:38:58

Re: xs - A less bad shell

#6 2009-12-26 12:04:10

Re: xs - A less bad shell

#7 2009-12-28 00:54:15

Re: xs - A less bad shell

#8 2009-12-28 08:22:15

Re: xs - A less bad shell

#9 2009-12-29 04:38:55

Re: xs - A less bad shell

#10 2009-12-29 05:26:28

Re: xs - A less bad shell

#11 2009-12-29 05:32:41

Re: xs - A less bad shell

#12 2009-12-29 08:21:58

Re: xs - A less bad shell

#13 2009-12-29 10:32:45

Re: xs - A less bad shell

#14 2009-12-29 22:27:40

Re: xs - A less bad shell

#15 2009-12-29 22:47:29

Re: xs - A less bad shell

#16 2009-12-29 23:38:03

Re: xs - A less bad shell

#17 2009-12-30 00:39:46

Re: xs - A less bad shell

#18 2009-12-30 01:12:13

Re: xs - A less bad shell

#19 2010-01-05 13:12:27

Re: xs - A less bad shell

#20 2010-01-05 23:26:11

Re: xs - A less bad shell

#21 2010-01-06 17:50:14

Re: xs - A less bad shell

#22 2010-01-07 13:44:20

Re: xs - A less bad shell

#23 2010-01-08 00:40:54

Re: xs - A less bad shell

#24 2010-02-11 23:53:35

Re: xs - A less bad shell

#25 2010-02-15 02:06:36

Re: xs - A less bad shell

Board footer