Re: [dev] sbase installed first impressions

From: stephen Turner <stephen.n.turner_AT_gmail.com>
Date: Mon, 3 Oct 2016 19:34:48 -0400

_AT_Evan
I am not too fluent at advanced shell at the moment so help me out
with this one please, I checked the advanced scripting guide but want
to make sure i understand this.

s() { ls -F "$_AT_" | cols; }
s() implies that you have created an alias for ls as "s" and the () is
to listen for what follows for the flags "-h etc"?
{} is to encapsulate the real commands,
ls -F "$_AT_" the "$@" is to pass along the flags from s()?
and for the ; at the end of cols, i assume this terminates in a way
that prevents it from grabbing further input?

_AT_FRIGN

On Mon, Oct 3, 2016 at 5:35 PM, FRIGN <dev_AT_frign.de> wrote:
> On Mon, 3 Oct 2016 17:23:50 -0400
> stephen Turner <stephen.n.turner_AT_gmail.com> wrote:
>
> Hey Stephen,
>
>> Background first. I'm running a simple kernel, busybox, make, pcc,
>> musl, binutils (patched for ash) environment. Its run from ram so i
>> can trash the environment as many times as i care to reboot. That
>> being said I decided to install suckless in place allowing it to
>> overwrite the busybox links just for kicks. So far just sbase was
>> installed.
>>
>> I had to tweak the config.mk (expected i assume?)
>> PREFIX=/
>> MANPREFIX=/usr/local/share/man (keeping with suckless default here,
>> removed variable)
>> CC=pcc
>> LDFLAGS= (removed -s as it was not supported)
>
> yes, it is expected to change config.mk for your environments. in 99%
> of the cases you don't need to change the defaults though.
>

Its defaulted to /usr/local, the programs are supposed to be in /bin
/sbin and /usr/(bin, sbin) respectively per standard unix correct? Or
was this intended so to work with stali?

>> It compiled and installed faster than expected but then the code was
>> smaller than expected too, very impressive size! Immediately i decided
>> to check and see if it overwrote the busybox links and it did but i
>> also noticed there is no color or column views? Reviewing the Readme
>> shows that color isn't listed as one of the removed features just fyi
>> unless it has a short hand from --color that i didn't know.
>
> This is because color is not part of Posix, but a GNUism. For column
> views, use the cols(1) utility that is shipped with sbase. There is no
> reason to implement that in each single utility. Just invoke
>
> ls | cols
>
> as you already found out yourself. The Unix philosophy states that you
> should have one tool that does one thing and does it well; in this case
> this is cols(1) whose only job is to columnize output. ls(1) is complex
> enough already, so we really don't want to worry about columnizing
> output as well.
>

I agree, and even though its an inconvenience i was happy to see this
done since cols can add this output format as desired making the rest
just scripts and such.

>> I have never had ls without color or column included (i'm spoiled) and
>> google isn't being overly helpful at the moment. I found the cols
>> command and ls | cols solved that so i can just create an alias, what
>> about getting color? Is there a suckless solution?
>
> The suckless solution is just not to use color at all. It takes a while
> to get used to, but it's really not necessary. It's like syntax
> highlighting.
>

Yea, its by no means a deal breaker. It boils down to convenience once
again and the ability to at a glance see the folder, link, file status
without a second command or list view. If anything i'm surprised there
isn't a program for it but i guess the old school way was with list
:-p i'm sure i will suck it up and work around it.

>> I see a few items have the -i removed, I can't say i use the
>> interactive mode but i assume you removed it due to redundancy and so
>> i'm curious how you would normally do that the suckless way.
>
> There is no compelling reason for interactive mode. rm(1) for instance
> is a tool and you should just use it properly. Give it the proper
> arguments and be done with it; write a thin wrapper script if you
> really want an interactive mode, but there really is no reason to have
> it. It's a gimmick, but maybe you can give really compelling reasons to
> include it.
>

Honestly i never use -i and get annoyed when its on by default. I
can't off hand think of a good use case other than keeping less
experienced people from wiping a system but isnt " rm -rf * " half the
fun of learning unix? *insert evil grin*

>> Otherwise i haven't used it much but seems to be just as expected, a
>> gnu comparable cli. I need to update my scripts and then i will start
>> using this instead of busybox.
>
> I'm glad you like it! If you find any bugs, please report them!
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Received on Tue Oct 04 2016 - 01:34:48 CEST