Re: [dev] dev

[Rene Kita]

On Sat, Feb 03, 2024 at 09:04:04PM +, NRK wrote:
> Having trouble unsubscribing? Worry not, coach NRK is at your service!
> For a fair pay of 1337 XMR, you'll receive:
> 
> ★★★ A comprehensive guide on how to unsubscribe from the suckless dev mailing 
> list ★★★
> 
> Offer available for a limited time only.
> 
> - NRK
> 

I heard the story about the early days, when mailing lists where new and
shiny, they had a unsubscribe mailing list where they forwarded those
unsubscribe emails. The sender address was subscribed to the unsubscribe
list, so they could get in touch with other people interested in talking
about unsubscribing mailing lists.

Re: [dev] dev

[Greg Minshall]

:)

Re: [dev] dev

[NRK]

Having trouble unsubscribing? Worry not, coach NRK is at your service!
For a fair pay of 1337 XMR, you'll receive:

★★★ A comprehensive guide on how to unsubscribe from the suckless dev mailing 
list ★★★

Offer available for a limited time only.

- NRK

[dev] dev

[Olivier Regnier]

Re: [dev] [DEV][Quark] Big problem

[fossy]

(replying to Laslo)
> which is basically a CGI-interface and thus not within quark's scope.

thttpd has a patch that adds basic CGI support, and I've quickly scanned the
patch, and it seems super simple.. perhaps you could use that in one way or
another.
I don't mean to say "support intellectual property" (I despise it), but
just to
warn you - I'm not sure what the license they use is.

Git? What a bloated mess.. I ahve been working on an Suckless thing alike it,
but my health :(


No, yeah, I absolutely understand.. but I think Quark can be good, if we just
fix this shitty problem lol.. like.. I got lots of hope in it, by which I
mean
you guys ._. sorry.
I just want Suckless software to succeed.. and last time I checked OpenBSD's
httpd code - it was NOT nearly as suckless lul.

Best regards
- anon

Re: [dev] [DEV][Quark] Big problem

[fossy]

Hey, Laslo.

Yeah, that's fine.. it's like "stable release" for normies.

Ah. I kind-of like Quark.. I don't want to go try thttpd..

It does NOT work XD
In fact - it seems to work much less.. like the opposite from before.
I get like the IP (localhost) dropped - -
usually it's IP (localhost) 200(or 403) somethingsomething.onion /

And this dropping began at literally the 3rd connection within like 5
minutes.. so it cannot be any sort of limit per-say.. except this time,
just on
this 3rd connection(from overall logs that I've seen), the log output was
this:
IP (localhost) 200 - /

I'm not sure if the logging is broken, but I rely on the manually loading the
site and checking if 0 bytes get received - which hasn't happened yet, of
course.


And you are right - you haven't given me any reason for such a threat, it
wasn't for you lol.. or perhaps it was a preventive advice rather than a
threat.. I forgot.. doesn't matter.. what matters is that you're trying to
help
and I'm thankful.. I hope misunderstandings don't happen anymore.

Re: [dev] [DEV][Quark] Big problem

[Laslo Hunhold]

On Sun, 26 Feb 2023 14:02:48 +0100
Thomas Oltmann  wrote:

Dear Thomas,

> Looks to me like your version of quark is actually a lot newer than
> 2020; Old versions of quark did not print that "dropped" message.
> 
> Probably only tangentially related,
> but I reported a bug in the connection dropping code some time ago,
> which meant that quark would likely drop legitimate connections under
> load (IP address comparison check was the wrong way 'round).
> I don't think the fix ever got merged ...

mea culpa, I postponed the merge planning to refactor some things, but
never got around to merging them. I have now merged them all, maybe
this already fixes the problem.

Sorry for making you wait so long for the merge, as I usually try to
respond fast.

With best regards

Laslo

Re: [dev] [DEV][Quark] Big problem

[fossy]

If you guys want - perhaps we can play the printf game, or rather - the
logging game?

Re: [dev] [DEV][Quark] Big problem

[fossy]

Ah, I see.
I forgot how to use git after such a long absence from programming.. +6
months.

I ran the command and it's up to date, last commit is
68b4f733b2755762e43df90f73db5a6ec8d14104 on both of my sites.

I see.
I can test the patch, but I don't think I'm using AF_INET6 as I disabled IPv6
in FreeBSD jail. Meaning the patch probably doesn't do anything for me.

Like I said - I increased -s and -t, but that doesn't seem to change
anything..
which is quite strange, is it not?

What are your thoughts on thttpd (https://www.acme.com/software/thttpd/)?
I see that Suckless isn't hosted by Quark,
either, would love to hear why is that, too.

Re: [dev] [DEV][Quark] Big problem

[Thomas Oltmann]

On Sun, Feb 26, 2023 at 3:53 PM  wrote:
>
> I did a git clone like it says on the main Quark web-site, and doing `mandoc
> -a quark.1` it shows '2020-09-27', and that's what I am using.
> Unless that's wrong and/or there's another way to get the version number -
> I'd
> like to know.

Ah i see. Running 'git clone' as described on the website does
actually download the latest version.
That date is simply when the last major changes where made to the
manpage, not quark itself.
If you run 'git log' you'll see the date of the most recent (topmost)
change to the source code.

> > which meant that quark would likely drop legitimate connections under load
> (IP address comparison check was the wrong way 'round). I don't think the fix
> ever got merged ...
>
> That's interesting. Like I said - 2020 version, is it fixed in newer commits,
> should I test that out as well?
>
> Because increasing -s and -t seems to do jack shit as I already stated :d

The bug still hasn't been fixed in the latest version.
I've attached a bug fix patch to this mail that you can use, but I'm not 100%
sure that this bug is responsible for your problem.
To apply the patch, simply drop the .diff file in your quark source
folder, then run
git am quark-addr_cmp_fix-20230226.diff
and then rebuild & reinstall with
make
make install
From 0fc2f684e79795dcc4cbd9888a0dd30d78aff36f Mon Sep 17 00:00:00 2001
From: Thomas Oltmann 
Date: Sun, 26 Feb 2023 17:38:43 +0100
Subject: [PATCH] Fix inverted conditional in sock_same_addr()

---
 sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sock.c b/sock.c
index ecb73ef..e6e7754 100644
--- a/sock.c
+++ b/sock.c
@@ -198,7 +198,7 @@ sock_same_addr(const struct sockaddr_storage *sa1, const struct sockaddr_storage
 	case AF_INET6:
 		return memcmp(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr,
 		  ((struct sockaddr_in6 *)sa2)->sin6_addr.s6_addr,
-		  sizeof(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr));
+		  sizeof(((struct sockaddr_in6 *)sa1)->sin6_addr.s6_addr)) == 0;
 	case AF_INET:
 		return ntohl(((struct sockaddr_in *)sa1)->sin_addr.s_addr) ==
 		   ntohl(((struct sockaddr_in *)sa2)->sin_addr.s_addr);
-- 
2.39.1

Re: [dev] [DEV][Quark] Big problem

[fossy]

I did a git clone like it says on the main Quark web-site, and doing `mandoc
-a quark.1` it shows '2020-09-27', and that's what I am using.
Unless that's wrong and/or there's another way to get the version number -
I'd
like to know.

> which meant that quark would likely drop legitimate connections under load
(IP address comparison check was the wrong way 'round). I don't think the fix
ever got merged ...

That's interesting. Like I said - 2020 version, is it fixed in newer commits,
should I test that out as well?

Because increasing -s and -t seems to do jack shit as I already stated :d

Thanks for your time, and please don't be such an asshole like the 2 guys
already did.. nothing is perfect, and I can also make you cry with facts
about
your life you did not even realize, so let's keep it friendly, shall we?

Re: [dev] [DEV][Quark] Big problem

[fossy]

> Reread Laslo's message and look at the source code as he suggested in
the mentioned message.

I cannot afford that, I have health problems :(.
Regardless - I am getting only ~5 requests per minute, and my biggest file
is <3M, so even given the attack has a super-slow Tor circuit connection
of say 50kbit/s - the connection pool which is by default 64 - shouldn't
be exhausted at the connection rate (~5/min).

Re: [dev] [DEV][Quark] Big problem

[Thomas Oltmann]

Hi fossy,
Looks to me like your version of quark is actually a lot newer than 2020;
Old versions of quark did not print that "dropped" message.

Probably only tangentially related,
but I reported a bug in the connection dropping code some time ago,
which meant that quark would likely drop legitimate connections under load
(IP address comparison check was the wrong way 'round).
I don't think the fix ever got merged ...

On Sat, Feb 25, 2023 at 8:12 PM Страхиња Радић  wrote:
>
> On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> > Tried -s 128 -t 8, doesn't seem to do jack shit..
> > Got less than 10 connection logs from Quark and then another dropped one..
> > Is there any other reason Quark would print-out 'dropped', other than
> > connection pool at max?
> >
> > I restarted the jail, so Quark's memory and stuff should have been reset.
>
> Reread Laslo's message and look at the source code as he suggested in the
> mentioned message.

Re: [dev] [DEV][Quark] Big problem

[Страхиња Радић]

On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> Tried -s 128 -t 8, doesn't seem to do jack shit..
> Got less than 10 connection logs from Quark and then another dropped one..
> Is there any other reason Quark would print-out 'dropped', other than
> connection pool at max?
> 
> I restarted the jail, so Quark's memory and stuff should have been reset.

Reread Laslo's message and look at the source code as he suggested in the 
mentioned message.


signature.asc
Description: PGP signature

Re: [dev] [DEV][Quark] Big problem

[fossy]

Tried -s 128 -t 8, doesn't seem to do jack shit..
Got less than 10 connection logs from Quark and then another dropped one..
Is there any other reason Quark would print-out 'dropped', other than
connection pool at max?

I restarted the jail, so Quark's memory and stuff should have been reset.

Re: [dev] [DEV][Quark] Big problem

[fossy]

Hey, I just read the quark.1 .
I see the -s and -t options lol. I shall experiment.

Re: [dev] [DEV][Quark] Big problem

[fossy]

Hi, Laslo.
Sorry, I might not have been best at explaining problem, but then again - I
didn't quite understand problem.. but said all I did understand.

> one of my development goals for quark was to have no memory allocations at
runtime.

Right, I knew that.. but what about memory allocation BEFORE runtime?

Also, worth nothing - I did the stable git clone which gives a 2020 version..
but there seems to be a lot of patches from 2021 and some are anti-DDoS.

It is also worth nothing that I did some resource limitation, but nothing too
extreme. Again - I am not running Facebook or over clear-net, so connections
should be much slower.

And yes - when using curl it shows localhost thing and when Tor - Tor
address.

I use rctl and limit openfiles.. and I guess that also goes for sockets..
should I increase this? Not a small number.
I guess open connections can be much frequent if I have big files and the
transfer speed is slow (like on Tor can be lol).. but shouldn't exceed
the
openfiles limit ..

According to Quark logs - I got like 8k connections in total, over a
period of
like 5 days.. unless there are some hidden connections - I don't see the HOW
the 'OOM KILLER' could be triggered.. and my biggest files are like less than
3M

Do I have an idea? I could have many ideas, but I cannot do jack shit because
of my health with eyes.. even doing this is a hard challange.. and is ruining
my health.


So - yeah.. how many open connections are by default - does it scale up by
some
sort of resource discovery?
How does Quark figure out how big the connection pool is? Does it figure
out at
all? XD.

Quark seems to be some sort of fail2ban, too, huh, since it immediately drops
stuff.. but only when at critical usage? If so - very cool.


Sorry I couldn't help more.. And being an asshole.. I usually have more
patience, but I am losing my sanity and the will to live as my health
declines.. I just want to write C again.. oh God I am crying right now..
*goes
to listen 'Dennis Ritchie - Write in C' while crying*.


It seems some buddy chad of mine found it only allows for 64 connections by
default.. but even then - it shouldn't be exceeded, right?
Perhaps I can like somehow monitor shit in more detail? Can I add some
sort of
printf on connection output?

Thanks for your time.. I fucking love you *cries again*.

- Friendly anon

Re: [dev] [DEV][Quark] Big problem

[fossy]

You are a brainless joke.

Re: [dev] [DEV][Quark] Big problem

[Hiltjo Posthuma]

On Sat, Feb 25, 2023 at 09:50:42AM -0500, fo...@dnmx.org wrote:
> Hello.
> Before I start, I want to clarify 2 things:
> 1. I'm not 100% sure if it's a Quark problem, but there are like 2/4th
> chance that it is.
> 2. I'm hosting my site over the Tor network
> 
> Problem I have: software runs, can access it from localhost via curl, but
> cannot access it from Tor
> 
> What happens when I try to access it from Tor? it seems to connect,
> but 0 bytes get transmited
> 
> wtf it suddendly started working
> 
> usually the fix is NOT restarting Tor, but restarting the jail and
> with it - Quark.. but it works via curl, which is confusing..
> 
> Not sure if Quark problem or Tor problem
> 
> In Quark log I get a message 'dropped'
> 
> I'd like to know if there's something I can do, like what key-words to
> look in Tor's logs
> 
> Also to mention: I am getting DDoS-ed for days now xD
> 
> I don't see any excessive CPU or memory usage, really - one of reasons
> I use Quark and a static web-site
> 
> 
> The main reason I think it's Quark's problem: restarting a FreeBSD jail
> with Quark running makes everything work again. This is also why I said
> 2/4 - 1/4 is Tor possible faulty, and the last 1/4 is perhaps something to
> do with FreeBSD jails.
> 
> The reason I thikn it's not Quark's problem: I can access it well with
> curl on localhost lol
> 
> I also wonder what "-   dropped   -" means.. and why is there no local
> interface IP address (the 1st '-')?
> 
> I helped with the logging to files with Quark bug, now I hope someone can
> help me with this.
> 
> 

Hi,

Have you tried watching the TOP 10 Quark Life Hacks video to solve the BIG
PROBLEM?

https://www.youtube.com/embed/SqaOZLuQfPg

Hope this helps and you'll get out of jail soon,

-- 
Kind regards,
Hiltjo

[dev] [DEV][Quark] Big problem

[fossy]

Hello.
Before I start, I want to clarify 2 things:
1. I'm not 100% sure if it's a Quark problem, but there are like 2/4th
chance that it is.
2. I'm hosting my site over the Tor network

Problem I have: software runs, can access it from localhost via curl, but
cannot access it from Tor

What happens when I try to access it from Tor? it seems to connect,
but 0 bytes get transmited

wtf it suddendly started working

usually the fix is NOT restarting Tor, but restarting the jail and
with it - Quark.. but it works via curl, which is confusing..

Not sure if Quark problem or Tor problem

In Quark log I get a message 'dropped'

I'd like to know if there's something I can do, like what key-words to
look in Tor's logs

Also to mention: I am getting DDoS-ed for days now xD

I don't see any excessive CPU or memory usage, really - one of reasons
I use Quark and a static web-site


The main reason I think it's Quark's problem: restarting a FreeBSD jail
with Quark running makes everything work again. This is also why I said
2/4 - 1/4 is Tor possible faulty, and the last 1/4 is perhaps something to
do with FreeBSD jails.

The reason I thikn it's not Quark's problem: I can access it well with
curl on localhost lol

I also wonder what "-   dropped   -" means.. and why is there no local
interface IP address (the 1st '-')?

I helped with the logging to files with Quark bug, now I hope someone can
help me with this.

Re: [dev] [ dev ] [ st ] [ PATCH ] concurrency window size bug

[Hiltjo Posthuma]

On Fri, Jun 05, 2020 at 03:05:49PM -0400, Kyryl Melekhin wrote:
> This bug is very exceptional and will only affect users who run other
> terminal programs with st.
> For example running
> " st -e vim . "
> " st -e lynx "
> etc ...
> 

Hi Kyryl,

Thanks for the report.

> The bug happens randomly, and on some systems may not even exist, very
> hard to reproduce and predict. On my system with clean st build
> changes are 50/50. Race condition depends heavily on timing. The
> problem lies in usage of fork() function inside ttynew() function.
> Basically what will happen is that the child program has a chance of
> getting wrong window dimensions assigned, and if that program is vim
> or lynx it will permanently mess up every single character in the
> program and rendering, If you can't reproduce the bug right now, just
> put usleep between
> 
> (x.c 1890):
> ttyfd = ttynew(opt_line, shell, opt_io, opt_cmd);
> 
> /*
> usleep doc: usec is greater than or equal to 100.  (On systems where
>   that is considered an error.)
> */
> /* Add this; value must not error, print Success */
> fprintf(stderr, "%s\n", strerror(usleep(99)));
> cresize(w, h);
> 

This part is incorrect: "The usleep() function returns the 0 if successful;
otherwise the -1 is returned and the global variable errno is set to indicate
the error. So it does not reset errno if it was succesful (happened on my
system).

So this would be better/good enough for debug printing:
errno = 0;
ret = usleep(99);
fprintf(stderr, "usleep, ret=%d, errno=%d, err=%s\n", ret, errno, 
strerror(errno));


> that should make it 100% consistent. Also use monocle layout in dwm to
> see better. I think this bug happens only if the child process starts
> to execute its own window dimensions code before st's calls cresize(w,
> h).
> That is why the sleep function makes the bug consistent.
> I propose a solution to this that worked for me:
> 
> diff --git a/x.c b/x.c
> index 210f184..fb80366 100644
> --- a/x.c
> +++ b/x.c
> @@ -1887,6 +1887,7 @@ run(void)
> }
> } while (ev.type != MapNotify);
> 
> +   cresize(w, h);
> ttyfd = ttynew(opt_line, shell, opt_io, opt_cmd);
> cresize(w, h);
> 
> Calling cresize before fork() ensures that the child starts with
> correct dimensions already set (since it inherits).
> For me this has reduced the chance of bug to 0%. However for some
> reasons I may not know if you still keep that
> usleep call there, things yet again go south. But on the other side,
> if this fix helped me to never ever experience
> the rendering corruption again, I think this is a worthy patch as it
> does not happen on hotpath of the program anyway.
> 

I believe the issue exists, but it is not solved correctly.
For example using cresize(w, h) before ttynew would do an ioctl() on a
non-existing fd.

Using st -e lynx and the usleep delay it will initialize with the default 
dimensions.
Not all the space in the terminal window is used, but no output is garbled here.
This is on OpenBSD -current.

What exact system do you use?

-- 
Kind regards,
Hiltjo

[dev] [ dev ] [ st ] [ PATCH ] concurrency window size bug

[Kyryl Melekhin]

This bug is very exceptional and will only affect users who run other
terminal programs with st.
For example running
" st -e vim . "
" st -e lynx "
etc ...

The bug happens randomly, and on some systems may not even exist, very
hard to reproduce and predict. On my system with clean st build
changes are 50/50. Race condition depends heavily on timing. The
problem lies in usage of fork() function inside ttynew() function.
Basically what will happen is that the child program has a chance of
getting wrong window dimensions assigned, and if that program is vim
or lynx it will permanently mess up every single character in the
program and rendering, If you can't reproduce the bug right now, just
put usleep between

(x.c 1890):
ttyfd = ttynew(opt_line, shell, opt_io, opt_cmd);

/*
usleep doc: usec is greater than or equal to 100.  (On systems where
  that is considered an error.)
*/
/* Add this; value must not error, print Success */
fprintf(stderr, "%s\n", strerror(usleep(99)));
cresize(w, h);

that should make it 100% consistent. Also use monocle layout in dwm to
see better. I think this bug happens only if the child process starts
to execute its own window dimensions code before st's calls cresize(w,
h).
That is why the sleep function makes the bug consistent.
I propose a solution to this that worked for me:

diff --git a/x.c b/x.c
index 210f184..fb80366 100644
--- a/x.c
+++ b/x.c
@@ -1887,6 +1887,7 @@ run(void)
}
} while (ev.type != MapNotify);

+   cresize(w, h);
ttyfd = ttynew(opt_line, shell, opt_io, opt_cmd);
cresize(w, h);

Calling cresize before fork() ensures that the child starts with
correct dimensions already set (since it inherits).
For me this has reduced the chance of bug to 0%. However for some
reasons I may not know if you still keep that
usleep call there, things yet again go south. But on the other side,
if this fix helped me to never ever experience
the rendering corruption again, I think this is a worthy patch as it
does not happen on hotpath of the program anyway.

Re: [dev] dev+unsubscr...@suckless.org

[David Phillips]

On Thu, Sep 15, 2016 at 10:05:46AM +0100, Joseph Graham wrote:
> hey

Hi

> -- 
> Joseph Graham 

Remember that it's the address, not the subject that should be dev+unsubscribe.

All the best

[dev] dev+unsubscr...@suckless.org

[Joseph Graham]

hey

-- 
Joseph Graham 

Re: [dev] dev+unsubscr...@suckless.org

[Jakub Lach]

> dev+unsubscr...@suckless.org

Your subscription has been prolonged.

[dev] dev+unsubscr...@suckless.org

[ret set]

dev+unsubscr...@suckless.org

[dev] [dev] [surf] [PATCH] replacing deprecating signal “title-changed” with “notify::title”

[Quentin Rameau]

As the subject of the mail tells, this is a simple signal handling
adjustment for page title modification.


0001-deprecating-signal-title-changed-for-notify-title.patch
Description: Binary data

[dev] Re: [dev] [dev] [surf] [PATCH] replacing deprecating signal “title-changed” with “notify::title”

[Quentin Rameau]

He is another one for signals populate-popup/context-menu.
I'm not sure that is really necessary, but here, it's done.

On Thu, Feb 6, 2014 at 7:15 PM, Christoph Lohmann 2...@r-36.net wrote:
 Greetings.

 On Thu, 06 Feb 2014 19:15:13 +0100 Quentin Rameau quinq...@gmail.com wrote:
 As the subject of the mail tells, this is a simple signal handling
 adjustment for page title modification.

 The patch has been applied. Thanks for sending it.


 Sincerely,

 Christoph Lohmann





0001-deprecating-signal-populate-popup-for-context-menu.patch
Description: Binary data

Re: [dev] dev+confunsub-27380ac57e2486a8-thuban=singularity...@suckless.org

[Chris Down]

You might want to try that using the right header :-)
On 13 Jun 2013 10:21, Thuban thu...@singularity.fr wrote:

[dev] dev+unsubscribe-dig...@suckless.org

[Johny Why]

dev+unsubscribe-dig...@suckless.org

Re: [dev] dev+unsubscribe-dig...@suckless.org

[Chris Hall]

On Wed, Dec 26, 2012 at 7:30 AM, Johny Why johny...@gmail.com wrote:
 dev+unsubscribe-dig...@suckless.org

You send a message to that address (body isn't important).

~cjh

[dev] dev+unsubscr...@suckless.org

[David Dušanić]

Re: [dev] dev+unsubscr...@suckless.org

[pancake]

Welcome to the suckless mailing list!

You have been succesfully subscribed again.

Ad eternum

On Aug 6, 2012, at 8:34, David Dušanić ivanovne...@googlemail.com wrote:

 

Re: [dev] dev+unsubscr...@suckless.org

[Anselm R Garbe]

Read

  http://suckless.org/community

to learn the unsubscription procedure.

Re: [dev] dev+unsubscr...@suckless.org

[Valentin Ochs]

On Mon, Aug 06, 2012 at 10:13:01AM +0200, Anselm R Garbe wrote:
 Read
 
   http://suckless.org/community
 
 to learn the unsubscription procedure.
 

Or the email headers...

Re: [dev] [dev xlsh]: fix Makefile

[Michał Siejak]

 With this patch, your Makefile works with my make (GNU Make 3.81)
Thanks for your patch. I modyfied Makefile accordingly and pushed it to github.

-- 
Michał Siejak

[dev] [dev xlsh]: fix Makefile

[Kurt Van Dijck]

On Wed, Oct 19, 2011 at 09:37:52PM +0200, Michał Siejak wrote:
 Hello.
[...]
 Source code is here: https://github.com/Nadrin/xlsh
 Example screenshot is here: https://github.com/Nadrin/xlsh/wiki
 
 If any of you guys find it useful let me know. :) Constructive
 criticism/peer review is more than welcome.

With this patch, your Makefile works with my make (GNU Make 3.81)

Signed-off-by: Kurt Van Dijck kurt.van.di...@eia.be
---
diff --git a/Makefile b/Makefile
index a1d2b13..541ea3b 100644
--- a/Makefile
+++ b/Makefile
@@ -38,7 +38,8 @@ XLSHD_HEADERS = config.h libxlsh.h
 
 all: $(PROGRAMS)
 
-xlsh: $(XLSH_OBJ) $(XLSH_LIBS)
+xlsh: $(XLSH_OBJ)
+xlsh: LDLIBS=$(XLSH_LIBS)
 
 xlshd: $(XLSHD_OBJ)
 

Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, syn opsis, …

[pancake]

80 or 78? :)

Sent from my iPod

On Aug 21, 2010, at 2:59 AM, Noah Birnel nbir...@gmail.com wrote:


On Thu, Aug 19, 2010 at 11:06:40AM -0700, Suraj Kurapati wrote:
On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati sun...@gmail.com  
wrote:

Alternatively, in simple shell scripts (for which writing a manpage
would be overkill), I simply print the script file's comment header
using sed(1):

#!/bin/sh
# your program description  usage documentation here
# nicely formatted and beautified to fit 80 columns
# NOTE: the blank line below is the end of the file comment header

# check command-line usage
if test $# -lt 3; then
 sed -n '2,/^$/s/^# \?//p' $0 # show this file's comment header
 exit 1
fi


That is beautiful.

-Noah

[dev] Re: [dev] Re: [dev] Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …

[Suraj Kurapati]

On Sat, Aug 21, 2010 at 4:22 AM, yy yiyu@gmail.com wrote:
 2010/8/19 Suraj Kurapati sun...@gmail.com:
 On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati sun...@gmail.com wrote:
 #!/bin/sh
 # your program description  usage documentation here
 # nicely formatted and beautified to fit 80 columns
 # NOTE: the blank line below is the end of the file comment header

  sed -n '2,/^$/s/^# \?//p' $0 # show this file's comment header

 I find this solution really convoluted. Why not using echo? You can
 use an USAGE variable, or even a here-document and cat if you feel
 like it.

I like to put documentation at the head of a file because that's only
part anyone will read before deciding if it's worth spending their
time to delve into the rest of the shell script.  Also, I don't like
messing up my program's indentation because I have to emit a big block
of text in it:

if ...; then# ugly!
  cat EOF
your documentation here
EOF
fi

 And btw, it would probably be a good idea to redirect the
 help message to stderr.

Good idea.

[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …

[Suraj Kurapati]

On Sat, Aug 21, 2010 at 2:12 AM, pancake panc...@youterm.com wrote:
 80 or 78? :)

Good point.  I personally use 78 because, if you follow the Python
suggestion of 79 characters and reserve 1 more character for +/-/
indicators in diff(1) output, then your code will be readable in
terminals, editors, and also in patches.

Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …

[Claudio M. Alessi]

On Tue, Aug 17, 2010 at 08:52:37PM +0400, anonymous wrote:
 usage: cmd [-abcde] [-f file] [-g pattern] [file ...]
What about cmd [-abcde] [-fg arg] [file ...]?

 usage: flo [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]]
With the above rules this should be: flo [-cfrtw arg] [what[,from][-to]]

Leaving the man page the task to teach the user what each option do.

It would be nice to have a guidelines with this and other stuff there, at least
for the suckless community.

[dev] Re: [dev] [dev] Usage, -h, --help, help, synopsis, …

[Alexander Teinum]

But we don’t need the brackets. As long as the usage text is
unambiguous, then they don’t add any information. Am I right?


Alexander

[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …

[Connor Lane Smith]

On 18 August 2010 15:37, Alexander Teinum atei...@gmail.com wrote:
 But we don’t need the brackets. As long as the usage text is
 unambiguous, then they don’t add any information. Am I right?

Two instances which make this untrue:

 ar [-]key archive [files...]
 eg [-b from to] files...

It also just makes the usage easier to read, in my opinion. Dropping a
few characters just isn't worth any loss in clarity. I did drop from
dmenu's usage the [-sb color] syntax, though.

Thanks,
cls

[dev] Re: [dev] Re: [dev] Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …

[Alexander Teinum]

(Sorry for not quoting names. It’s cumbersome to do with more than one
person in Gmail.)

 With the above rules this should be: flo [-cfrtw arg] [what[,from][-to]]

I think that’s too little information.

 It also just makes the usage easier to read, in my opinion. Dropping a
 few characters just isn't worth any loss in clarity.

Valid point. Make things as simple as possible, but not simpler. :)

From the information that I have now, then I would think that this
should be fine:

usage: program [-a] [-b] [-c] [-f file] [-n number] blah
usage: flo [-a] [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]]

I’d like to write a KISS option parser that accepts “program -c -a -f
some_file”, but not “program -ca -fsome_file”. I prefer to keep the
rules simple.

Is it okay to use three dots in the usage text? (See echo’s man page.)
I think it means that you can repeat what’s before the three dots.

How do you feel about sorting the options? Should it always be done?

[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …

[Anh Hai Trinh]

On Wed, Aug 18, 2010 at 10:27 AM, Kris Maglione maglion...@gmail.com wrote:

 GNU man has the annoying and difficult to stop habit of filling the entire
 width of the terminal rather than wrapping at 80 chars. And if you set
 $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up
 with badly broken wrapping. As for bold, fortunately my terminal has it
 disabled, and reverse video has no place in manual pages.


$MANWIDTH can be abused to some extend:

$ cat grepman
#!/bin/sh
MANWIDTH=32767 exec man $2 | grep --color=auto -C2 -- $1


Set a bigger number for your own amusement.


-- 
@chickamade

[dev] Re: [dev] Re: [dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, synopsis, …

[Connor Lane Smith]

2010/8/18 Alexander Teinum atei...@gmail.com:
 I’d like to write a KISS option parser that accepts “program -c -a -f
 some_file”, but not “program -ca -fsome_file”. I prefer to keep the
 rules simple.

Such a simple option set probably doesn't actually *need* a parser. I
don't think any lines would be freed up in dmenu. You'd just add code.
It's got a for loop and a list of strcmps, plus usage(), which could
be done with a goto but I wasn't sure if that's suckless. It's
really the simplest implementation out there.

 Is it okay to use three dots in the usage text? (See echo’s man page.)
 I think it means that you can repeat what’s before the three dots.

I think files... means 1 or more file, and [files]... means 0 or more.

 How do you feel about sorting the options? Should it always be done?

I think it should be in the order the programmer gives them. Some
options may be more important, for example.

cls

Re: [dev] Re: [dev] Re: [dev] Re : [dev] [dev] Usage, -h, --help, help, synops is, …

[anonymous]

On Wed, Aug 18, 2010 at 05:55:10PM +0200, Alexander Teinum wrote:
 Is it okay to use three dots in the usage text? (See echo’s man page.)
 I think it means that you can repeat what’s before the three dots.

It is ok and they should be used.  And it should be 3 dots, not … so
usage is in ASCII.  And … look bad with monospace font.

 How do you feel about sorting the options? Should it always be done?

IMO yes.

Re: [dev] Re: [dev] Re: [dev] Re : [dev] [dev] Usage, -h, --help, help, synops is, …

[Jacob Todd]

On Wed, Aug 18, 2010 at 05:55:10PM +0200, Alexander Teinum wrote:
 I’d like to write a KISS option parser that accepts “program -c -a -f
 some_file”, but not “program -ca -fsome_file”. I prefer to keep the
 rules simple.
take a look at the ARGBEGIN and ARGEND macro's in Plan 9.


pgpoEUvuWrFez.pgp
Description: PGP signature

Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …

[anonymous]

On Tue, Aug 17, 2010 at 05:40:40PM +0200, Alexander Teinum wrote:
 What is the most concise way of outputting a usage and help text?
 
 Must the usage text be unambiguous when it comes to valid combinations?

No, compatibility of options should be described in man page.

 What should the program option or options be named that show the usage
 or help text?

There should be no help options at all: if you need help, use man
page.  Usage should be displayed when program is called with wrong
options.

 Are there any existing standards for usage and help text?
 
 How should the usage text and help text be formatted?
 
 – Keep it within 80 characters?
 – Use of whitespace
 – Use of lower- and uppercase
 – Wether to use “typographical correct” punctuation marks (“, ”, ‘, ’,
 … instead of , , ', ', ...) or not

I think the best format for usage is something like what Plan 9
utilities use (BSD use the same):

usage: cmd [-abcde] [-f file] [-g pattern] [file ...]

With these rules flo usage should be

usage: flo [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]]

 E-mail from pancake:
 
  The help messages in unix have different standards. And they aim to be
  short, simple and keep some common rules. The reason is because this way you
  can read them faster.
 
  In bsd. Help message is just one line. If you want description you have to
  refer to the manpage or readme.
 
  In gnu they tend to display a 4screenscrolling help message which is really
  anoying.
 
  Theorically the help length is another way to measure the complexity of the
  program.
 
  feel free to fwd this mail to the mailing list and continue the discussion
  there. It can be another interesting topic.
 
  For flo. I would suggest a oneline help or maybe somethung like this:
 
  flo [-r id] [-wch] [msg]
  -r id : remove reminder with id.
  ...
 
  Im just telling the flags as an idea.
 
  another thing..is that in suckless sw we usually prefer to not use getopt.
  The code looks ok. But the implementation in libc is horrendous. So a single
  switchcase would be better.

That depends on what libc you use.  GNU libc sort arguments so options
go first, BSD implementation is simplier.

[dev] Re: [dev] [dev] Usage, -h, --help, help, synopsis, …

[Alexander Teinum]

 I think the best format for usage is something like what Plan 9
 utilities use (BSD use the same):

 usage: cmd [-abcde] [-f file] [-g pattern] [file ...]

Options without values are combined? Is that correct?

 With these rules flo usage should be

 usage: flo [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]]

What if the values are of the same type? -c and -r have id as value.
-f and -t have date as value. I think your usage-text looks prettier,
but out of curiosity, can they be combined like this?

usage: flo [-cr id] [-ft date] …

If I decide to ditch getopt(), then I’d like to be able to type “flo
-c -f” to clear the from-field, which means that -f and -t have
optional arguments. Is it valid for an option to have an optional
argument?

If it is, which of the following is correct?

1. usage flo: [-f [from]] [-t [to]]

2. usage flo: [-ft] [-f from] [-t to]

3. usage flo: [-f from] [-t to]

4. usage flo: [-ft]

I found some guidelines here:

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_01c

Do you agree with the guidelines listed in 12.2? I’ll find a pen and a
paper and try to digest those.

[dev] Re: [dev] [dev] Usage, -h, --help, help, synopsis, …

[Suraj Kurapati]

On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum atei...@gmail.com wrote:
 What is the most concise way of outputting a usage and help text?

For my programs, the --help option simply displays their manpage. :-)

man(1) is better suited for information display (text-wrapping to 80
characters or $COLUMNS, pagination, and emphasis with bold, reverse
video, underline, etc.) than anything I could care to reinvent poorly
in each of my programs.

Re: [dev] Re: [dev] [dev] Usage , -h, --help, help, synopsis, …

[Kris Maglione]

On Tue, Aug 17, 2010 at 07:54:44PM -0700, Suraj Kurapati wrote:

On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum atei...@gmail.com wrote:

What is the most concise way of outputting a usage and help text?


For my programs, the --help option simply displays their manpage. :-)

man(1) is better suited for information display (text-wrapping to 80
characters or $COLUMNS, pagination, and emphasis with bold, reverse
video, underline, etc.) than anything I could care to reinvent poorly
in each of my programs.


GNU man has the annoying and difficult to stop habit of filling 
the entire width of the terminal rather than wrapping at 80 
chars. And if you set $MANWIDTH or $COLUMNS to 80 and the 
terminal isn't that wide, you wind up with badly broken 
wrapping. As for bold, fortunately my terminal has it disabled, 
and reverse video has no place in manual pages.


By the way, this is the script I use to launch man. If anyone 
knows of something better (other than Plan 9 man which 
unfortunately can't handle system man pages), please tell me:


#!/bin/rc
*=`{stty size} {
cols = $2
}

MANWIDTH=`{9 bc!}
if($cols = 72) print 72
if($cols  72) {
if($cols = 65) print 65
if($cols  65) print $cols
}
!
exec /usr/bin/man $* | 9 tr − - | less

--
Kris Maglione

He hoped and prayed that there wasn't an afterlife.  Then he realized
there was a contradiction involved here and merely hoped that there
wasn't an afterlife.
--Douglas Adams

[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …

[Suraj Kurapati]

On Tue, Aug 17, 2010 at 8:27 PM, Kris Maglione maglion...@gmail.com wrote:
 GNU man has the annoying and difficult to stop habit of filling the entire
 width of the terminal rather than wrapping at 80 chars. And if you set
 $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up
 with badly broken wrapping.

Agreed.  GNU man really should do something like CSS's max-width: 80em.

 As for bold, fortunately my terminal has it disabled,

I set up nice colors for bold and underline so things are easy to read
(see the attached screenshot).  If anyone is interested, my Xdefaults
file is here:

  http://github.com/sunaku/home/blob/master/.Xdefaults

 and reverse video has no place in manual pages.

Hehe, I went a little overboard there. :-)
attachment: man_colors.png

[dev] dev+unsubscribe, I think it is better to avoid the bloat

[mobi phil]

Well, I had a funny day here, but I think I knocked at the wrong door...

By the way. Ion3 is less bloated than any of the wi, wii, wi,
wii or drm... Isn't it a bloat or not suckles to have the same 3
times?

Anders Andersson said You're insane. Two of them in the same place
is too dangerous. I will respect Marvin Vek suggestion Mobi - Go

good luck, and please be suckless!


rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat

[Kurt H Maier]

On Fri, May 14, 2010 at 5:55 PM, mobi phil m...@mobiphil.com wrote:
 By the way. Ion3 is less bloated than any of the wi, wii, wi,
 wii or drm... Isn't it a bloat or not suckles to have the same 3
 times?

Has anyone really been far even as decided to use even go want to do
look more like?


-- 
# Kurt H Maier

Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat

[Marvin Vek]

On Sat, May 15, 2010 at 12:35:41AM +0200, hiro wrote:
 That's why I always said suckless is stupid. People have too high
 expectations when they read it!

It's not plan9 enough!!

-- 
Marvin Vek
-
/*
 * We used to try various strange things. Let's not.
 */
linux-2.2.16/fs/buffer.c

Re: [dev] dev+unsubscr...@suckless.org

[Anselm R Garbe]

2009/11/10 Kris Maglione maglion...@gmail.com:
 On Mon, Nov 09, 2009 at 07:20:28PM -0600, tosh wrote:

 For fucks sake it's not that big of a deal is it? I don't read the
 discussions, hence the unsubscribe. Gmail adds an unsubscribe link,
 apparently it doesn't work. No need to be a dick.

 It really is, given the frequency of these things, and the frequency of the
 other noise on the list.

Well, you started unsubscribing people manually, now it's your fault ;)

Kind regards,
Anselm

[dev] dev+unsubscribe

[Robert C Corsaro]

dev+unsubscribe

Re: [dev] dev+unsubscribe

[markus schnalke]

[2009-11-09 09:35] Kris Maglione maglion...@gmail.com 
 On Mon, Nov 09, 2009 at 09:30:41AM -0500, Robert C Corsaro wrote:
 dev+unsubscribe
 
 Annoying, isn't it? How many people do I have to manually 
 unsubscribe?

Aren't they able to take a look at the List-Unsubscribe header?


meillo

[dev] dev+unsubscr...@suckless.org

[tosh]

unsubscribe

Re: [dev] dev+unsubscr...@suckless.org

[Kris Maglione]

On Mon, Nov 09, 2009 at 06:16:43PM -0600, tosh wrote:

unsubscribe


For fuck's sake! It's not that hard, and we've just had this 
discussion. Well, I hope you can figure this one out yourself, 
or I suppose you'll have to stay subscribed.


--
Kris Maglione

Pessimists, we're told, look at a glass containing 50% air and 50%
water and see it as half empty.  Optimists, in contrast, see it as
half full.  Engineers, of course, understand the glass is twice as big
as it needs to be.
--Bob Lewis

Re: [dev] dev+unsubscr...@suckless.org

[tosh]

On Mon, Nov 9, 2009 at 6:30 PM, Kris Maglione maglion...@gmail.com wrote:

 On Mon, Nov 09, 2009 at 06:16:43PM -0600, tosh wrote:

 unsubscribe


 For fuck's sake! It's not that hard, and we've just had this discussion.
 Well, I hope you can figure this one out yourself, or I suppose you'll have
 to stay subscribed.

 --
 Kris Maglione

 Pessimists, we're told, look at a glass containing 50% air and 50%
 water and see it as half empty.  Optimists, in contrast, see it as
 half full.  Engineers, of course, understand the glass is twice as big
 as it needs to be.
--Bob Lewis



For fucks sake it's not that big of a deal is it? I don't read the
discussions, hence the unsubscribe. Gmail adds an unsubscribe link,
apparently it doesn't work. No need to be a dick.

Re: [dev] dev+unsubscr...@suckless.org

[Kris Maglione]

On Mon, Nov 09, 2009 at 07:20:28PM -0600, tosh wrote:

For fucks sake it's not that big of a deal is it? I don't read the
discussions, hence the unsubscribe. Gmail adds an unsubscribe link,
apparently it doesn't work. No need to be a dick.


It really is, given the frequency of these things, and the 
frequency of the other noise on the list.


--
Kris Maglione

I'm confident that tomorrow's Unix will look like today's Unix, only
cruftier.
--Russ Cox