On Thu, Sep 15, 2016 at 2:34 PM, Greg Reagle wrote:
> My two cents...
> Granted that rc+mk are far superior to /bin/sh+GNU make, but if there
> are already 3rd party (i.e. not from suckless) packages/programs that
> depend on sh+gmake, you might as well just use them as is. Doing a
> whole lot of
On Thu, Sep 15, 2016, at 10:56 AM, Evan Gates wrote:
> On Thu, Sep 8, 2016 at 10:29 PM, Anselm R Garbe
> wrote:
> > Nevertheless, after an excursion to sh for several years, I'm kind of
> > favouring 9base/rc again, after all. For stali I now tend to adopt rc
> > as primary scripting language for
On Thu, Sep 8, 2016 at 10:29 PM, Anselm R Garbe wrote:
> Nevertheless, after an excursion to sh for several years, I'm kind of
> favouring 9base/rc again, after all. For stali I now tend to adopt rc
> as primary scripting language for the target system as well. For the
> build host environment I w
On Fri, Sep 9, 2016, at 11:05 AM, Greg Reagle wrote:
> On Fri, Sep 9, 2016, at 10:27 AM, Evan Gates wrote:
> > Well that makes the suckless.org shell styleguide nice and simple:
> >
> > Use rc.
>
> Here here!
It's supposed to be hear, hear!
http://grammarist.com/spelling/hear-hear/
On Fri, Sep 9, 2016, at 10:27 AM, Evan Gates wrote:
> Well that makes the suckless.org shell styleguide nice and simple:
>
> Use rc.
Here here!
On Thu, Sep 8, 2016 at 10:29 PM, Anselm R Garbe wrote:
> I appreciate your efforts of coming up with some sh styleguide. A side
> note to that, I prefer calling test explicitely, instead of using the
> weirdo [ ] symlinks in while/if statements.
>
> Nevertheless, after an excursion to sh for sever
that's a good point, anselm :)
Hi there,
On 6 September 2016 at 20:35, Evan Gates wrote:
> suckless.org projects have traditionally been small amounts of pure C.
> The code tends towards simplicity and correctness. I value this and
> have learned much over the past years from reading and contributing to
> various projects.
>
>
You're wrong kamil. my computer has a working border patrol that
ensures your crappy files don't end up here. I never have to deal with
such shitty file names.
On 9/8/16, Kamil Cholewiński wrote:
> On Thu, 08 Sep 2016, Nick wrote:
>> I am against writing scripts that can deal with filenames with
On Thu, 08 Sep 2016, Nick wrote:
> I am against writing scripts that can deal with filenames with
> newlines. Fuck such filenames. If you have to deal with them, shell
> scripting is a terrible technology to use.
And since you never know when you'll have to deal with them...
On Thu, Sep 8, 2016 at 7:30 AM, Nick wrote:
> I am against writing scripts that can deal with filenames with
> newlines. Fuck such filenames. If you have to deal with them, shell
> scripting is a terrible technology to use.
I too think newlines in filenames is stupid. I never put newlines in
my f
On Thu, Sep 8, 2016 at 7:26 AM, Greg Reagle wrote:
> On Thu, Sep 8, 2016, at 10:11 AM, Greg Reagle wrote:
>> On Thu, Sep 8, 2016, at 10:05 AM, Kamil Cholewiński wrote:
>> > Wow, shell quoting is just fucked up crazy. I was mostly using unquoted
>> > $@ my whole life. And here I thought I knew enou
Quoth Evan Gates:
> On Thu, Sep 8, 2016 at 5:44 AM, Nick wrote:
> > I think this is something one learns with time. There are several
> > good reasons not to quote substitutions, such as passing multiple
> > arguments to another program (e.g. cmd $@), or a for or case
> > statement. But yes, quoti
On Thu, Sep 8, 2016, at 10:11 AM, Greg Reagle wrote:
> On Thu, Sep 8, 2016, at 10:05 AM, Kamil Cholewiński wrote:
> > Wow, shell quoting is just fucked up crazy. I was mostly using unquoted
> > $@ my whole life. And here I thought I knew enough not to screw up a
> > simple script,
>
> It is common
On Thu, Sep 8, 2016, at 10:05 AM, Kamil Cholewiński wrote:
> Wow, shell quoting is just fucked up crazy. I was mostly using unquoted
> $@ my whole life. And here I thought I knew enough not to screw up a
> simple script,
It is common knowledge to always double-quote $@, i.e. "$@", in
Bourne/Posix
On Thu, Sep 8, 2016 at 4:11 PM, Greg Reagle wrote:
> On Thu, Sep 8, 2016, at 10:05 AM, Kamil Cholewiński wrote:
>> Wow, shell quoting is just fucked up crazy. I was mostly using unquoted
>> $@ my whole life. And here I thought I knew enough not to screw up a
>> simple script,
>
> It is common know
On Thu, 08 Sep 2016, Evan Gates wrote:
> No. $@ is another example of something that _must_ be quoted every
> time. When inside quotes the shell expands it correctly to a word for
> each parameter. Without quotes the shell will do extra word splitting
> and globbing. For example, try this:
>
> nar
On Wed, Sep 7, 2016 at 11:21 PM, Martin Kühne wrote:
> As with read's -r flag, use <<'EOF' unless silly/potentially
> devastating side effects are desired.
To add on to this, if reading lines, use IFS= as well so you don't
lose leading/trailing whitespace. e.g.:
while IFS= read -r line; do
s
On Thu, Sep 8, 2016 at 12:27 AM, wrote:
> is there a special reason people use `EOF` rather than anything else.
> FWIW, I use a dot. looks very clear and natural to me, saves some
> keystrokes, feels right, just as ending a sentence with full stop.
>
> cat <<.
> 1st line
> 2nd line
> 3rd line
> 4
On Thu, Sep 8, 2016 at 5:44 AM, Nick wrote:
> I think this is something one learns with time. There are several
> good reasons not to quote substitutions, such as passing multiple
> arguments to another program (e.g. cmd $@), or a for or case
> statement. But yes, quoting is essential most of the
Hi Evan, I agree with most of your thoughts, I'll just add my own
where they differ.
> Shebang: Use #!/bin/sh and only use POSIX shell features. If you need
> bash features use the proper shebang, either #!/path/to/bash or
> #!/usr/bin/env bash
No suckless project should be using bash. If you ne
* Marc Collin 2016-09-08 05:04
> What people here think of heredoc?
>
> cat << EOF
> 1st line
> 2nd line
> 3rd line
> 4th line
> EOF
is there a special reason people use `EOF` rather than anything else.
FWIW, I use a dot. looks very clear and natural to me, saves some
keystrokes, feels right, ju
As with read's -r flag, use <<'EOF' unless silly/potentially
devastating side effects are desired.
cheers!
mar77i
What people here think of heredoc?
cat << EOF
1st line
2nd line
3rd line
4th line
EOF
OR
echo "1st line"
echo "2nd line"
echo "3rd line"
echo "4th line"
OR
printf "1st line\n"
printf"2nd line\n"
printf"3rd line\n"
printf"4th line\n"
On Wed, Sep 7, 2016 at 6:46 PM, Tiago Natel de Moura
wrote
Good compilation of best practices. That's one of the causes I created
nash[1], a shell with sane defaults.
1. https://github.com/NeowayLabs/nash
--
[]'s
i4k
Thanks!
On Thu, Sep 8, 2016 at 12:29 AM, Evan Gates wrote:
> On Wed, Sep 7, 2016 at 2:11 PM, Adrian Grigore
> wrote:
>> Rendering was just an example, I doubt a shell script would be rendering.
>>
>> Example of camelCase I find ok is here:
>> https://raw.githubusercontent.com/adriangrigore/boots
On Wed, Sep 7, 2016 at 2:11 PM, Adrian Grigore
wrote:
> Rendering was just an example, I doubt a shell script would be rendering.
>
> Example of camelCase I find ok is here:
> https://raw.githubusercontent.com/adriangrigore/bootstrap/master/bootstrap
>
> Be free to critique the script, but note th
Rendering was just an example, I doubt a shell script would be rendering.
Example of camelCase I find ok is here:
https://raw.githubusercontent.com/adriangrigore/bootstrap/master/bootstrap
Be free to critique the script, but note that I'm new to the whole
UNIX/C scene so learning as I go (if I di
On Wed 07 Sep 2016 at 11:43:48 PDT Adrian Grigore wrote:
Tbh, I'm nor a big fan of camelCase either, but when dealing with
names composed of multiple words, it looks cleaner to me.
renderimage vs renderImage
It's mostly a matter of taste. But as someone whose tastes
were formed by the naming
Tbh, I'm nor a big fan of camelCase either, but when dealing with
names composed of multiple words, it looks cleaner to me.
renderimage vs renderImage
On Wed, Sep 7, 2016 at 8:21 PM, Adrian Grigore
wrote:
> Tbh, I'm nor a big fan of camelCase either, but when dealing with names
> composed of mul
On Tue, 6 Sep 2016 11:35:35 -0700
Evan Gates wrote:
> suckless.org projects have traditionally been small amounts of pure C.
> The code tends towards simplicity and correctness. I value this and
> have learned much over the past years from reading and contributing to
> various projects.
>
> The
On Wed, 7 Sep 2016 03:23:55 +0300
Adrian Grigore wrote:
> What do you think of camelCase names for functions/variables?
For me it's important being consistent, at least on a project level
(across projects would be the best).
I personally dislike camelCase but are good to save columns.
--
---
On Tue, Sep 6, 2016, at 08:23 PM, Adrian Grigore wrote:
> What do you think of camelCase names for functions/variables?
Fine with me. I don't have a_strong_preference forEitherStyle.
On Tue, Sep 6, 2016 at 5:23 PM, Adrian Grigore
wrote:
> What do you think of camelCase names for functions/variables?
I personally am against camel case in all my code.
What do you think of camelCase names for functions/variables?
On Tue, Sep 6, 2016 at 11:53 PM, Greg Reagle wrote:
> On Tue, Sep 6, 2016, at 03:27 PM, Evan Gates wrote:
>> Sadly there is a lot of software these days that requires bash.
>> Hopefully we can avoid most of it, but I'm sure it'll pop u
On Tue, Sep 6, 2016, at 03:27 PM, Evan Gates wrote:
> Sadly there is a lot of software these days that requires bash.
> Hopefully we can avoid most of it, but I'm sure it'll pop up now and
> then. I'd say anything that can't be done well/safely in sh should be
> done in rc, but bash is ubiquitous.
On 09/06/16 22:14, Evan Gates wrote:
>> This is sometimes true, but printf is not safe as well from that point
>> > of view,
>> > as it's a builtin as well in most shells.
> It's not about builtin vs external, it's about surprises. Whether
> printf if builtin or not, it will behave in a predictable
On Tue, Sep 6, 2016 at 1:09 PM, Antenore Gatta wrote:
> Remember to quote whatever is inside the the substitute commands and
> that you can
> nest them:
>
> $(whatever "$foo" $(othercmd "$bar"))
almost, you'd need
"$(whatever "$foo" "$(othercmd "$bar")")"
as "$()" needs to be quoted as well
>
My bad... Sorry for the mail format.
On 09/06/16 22:09, Antenore Gatta wrote:
> Hi Evan!
>
> Thanks for this, it's something I can finally be involved (at least I hope).
>
> On 09/06/16 20:35, Evan Gates wrote:
>
>> Shebang: Use #!/bin/sh and only use POSIX shell features. If you need
>> bash fea
On 09/06/16 22:07, Evan Gates wrote:
> On Tue, Sep 6, 2016 at 12:51 PM, Thomas Levine <_...@thomaslevine.com> wrote:
>> Adherence to standards and legibility can be problematic if you care
>> about
>> portability to sucky systems and shells. For example, `...` is more
>> widely
>> supported than $(
Hi Evan!
Thanks for this, it's something I can finally be involved (at least I hope).
On 09/06/16 20:35, Evan Gates wrote:
> Shebang: Use #!/bin/sh and only use POSIX shell features. If you need
> bash features use the proper shebang, either #!/path/to/bash or
> #!/usr/bin/env bash
I agree with
On Tue, Sep 6, 2016 at 12:51 PM, Thomas Levine <_...@thomaslevine.com> wrote:
> Adherence to standards and legibility can be problematic if you care
> about
> portability to sucky systems and shells. For example, `...` is more
> widely
> supported than $(...). But in the case of stali, I suggest th
#!/usr/bin/env bash is necessary if you are using bash. But don't use
bash.
Here are some useful references on sh.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html
http://blackskyresearch.net/shelltables.txt
http://blackskyresearch.net/try.sh.txt
Adherence to standards and
> Sadly there is a lot of software these days that requires bash.
Nothing important that needs to be part of suckless projects anyway.
You have to pick, indeed, between plan9 compatible, rc shell, or posix
compatible: bourne shell. Anything else is a waste of time imo. If
these two options aren't
On Tue, Sep 6, 2016 at 12:10 PM, hiro <23h...@gmail.com> wrote:
> to me it sounds overly cautious, like a shell equivalent of: never use
> goto, always use braces, etc.. i don't like writing like this.
Most of it is avoiding things that are broken by design, like code
that can't handle filenames t
to me it sounds overly cautious, like a shell equivalent of: never use
goto, always use braces, etc.. i don't like writing like this.
using bash features should not be allowed *at all*, so neither
#!/path/to/bash or #!/usr/bin/env bash is ok.
#!/usr/bin/env is always wrong, /bin/sh is the only rig
On Tue, Sep 6, 2016 at 12:07 PM, Ali H. Fardan wrote:
> one more thing, multiline vs one-line statements:
>
> if [ expr ... ]; then
> ...
> fi
>
> versus
>
> if [ expr ... ]
> then
> ...
> fi
>
> this applies to others as well:
>
> while [ expr ... ]
> do
> ...
> done
>
> I'd stick wit
one more thing, multiline vs one-line statements:
if [ expr ... ]; then
...
fi
versus
if [ expr ... ]
then
...
fi
this applies to others as well:
while [ expr ... ]
do
...
done
I'd stick with the multiline style, what about you?
On 2016-09-06 21:35, Evan Gates wrote:
suckless.o
On Tue, Sep 6, 2016 at 11:59 AM, S. Gilles wrote:
> Perhaps http://www.etalabs.net/sh_tricks.html might be a useful reference
> to add? There's some detail there that might be valuable, or at least
> sobering to anyone who wants to write some complicated sh.
Definitely! It's a great resource.
On 2016-09-06T11:35:35-0700, Evan Gates wrote:
> Please discuss,
Perhaps http://www.etalabs.net/sh_tricks.html might be a useful reference
to add? There's some detail there that might be valuable, or at least
sobering to anyone who wants to write some complicated sh.
--
S. Gilles
signature.asc
suckless.org projects have traditionally been small amounts of pure C.
The code tends towards simplicity and correctness. I value this and
have learned much over the past years from reading and contributing to
various projects.
The addition of stali means there will probably be a fair amount of
sh
51 matches
Mail list logo
