GCC, probably. Which sucks, but if Hitler warns you not to step of a
cliff, you don't ignore his warning because he is Hitler.
On Tue, Sep 6, 2016 at 5:02 AM, Staven wrote:
> On Thu, Sep 01, 2016 at 11:28:03AM -0300, Marc Collin wrote:
>> Hey guys.
>>
>> I was warned by the compiler about a misle
Yeah, it's GCC version 6, I like your comparison ;)
On Tue, Sep 6, 2016 at 4:37 AM, Kevin Michael Frick wrote:
> GCC, probably. Which sucks, but if Hitler warns you not to step of a
> cliff, you don't ignore his warning because he is Hitler.
>
> On Tue, Sep 6, 2016 at 5:02 AM, Staven wrote:
>>
BTW since I got the warning too, sending the patch below.
--- a/paste.c
+++ b/paste.c
@@ -67,9 +67,10 @@
if (c == 0 && last != -1) {
if (i == fdescrlen - 1)
putchar('\n');
- else
+ e
On Tue, 6 Sep 2016 09:37:09 +0200
Kevin Michael Frick wrote:
> GCC, probably. Which sucks, but if Hitler warns you not to step of a
> cliff, you don't ignore his warning because he is Hitler.
I can understand the point you are making about GCC, but what is wrong
with Hitler? /s
--
FRIGN
On Tue, Sep 06, 2016 at 09:37:09AM +0200, Kevin Michael Frick wrote:
> GCC, probably. Which sucks, but if Hitler warns you not to step of a
> cliff, you don't ignore his warning because he is Hitler.
I never said it's a bad thing.
Please don't put words in my mouth.
I only let very close friends p
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
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
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.
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 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
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
> I only let very close friends put things in my mouth
I hope this is not a commercial offer, as such are not tolerated on
this mailing list.
stop being dorks without a good reason.
On 9/6/16, Staven wrote:
> On Tue, Sep 06, 2016 at 09:37:09AM +0200, Kevin Michael Frick wrote:
>> GCC, probably.
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
> 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
#!/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
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
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 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 $(
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 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
>
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 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.
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 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.
24 matches
Mail list logo
