Re: [hackers] [st][PATCH] sgr-patch

Hi Mikhail, > Colon-separated SGR (new version; ':' is the legacy one) Could explain a bit more what this patch is about, with some context and telling the goal?

Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau

> Hi, Hola k0ga, > > st would always move back 1 column, > > even with wide glyhps (using more than a single column). > > > > The glyph rune is set on its first column, > > and the other ones are to 0, > > so loop until we detect the start of the previous glyph. > >

Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode

> > I guess that the original intent of the code here > > was to to find any executable file. > > I concur. It seems to me that the default output mode for `cc` is 755 > even if the parent directory has more restrictive permissions. So the > more concise -perm -111 should suffice. I will leave

Re: [hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode

> Hi Quentin, Hola Randy, > > -find . ! -name . -prune -type f -perm /111 | > > +find . ! -name . -prune -type f \( -perm -u+x -o -perm -g+x -o -perm o+x > > \) | > > I believe `-perm -111` is equivalent and specified by POSIX. Not exactly, -perm -111 matches if at least the mode has

[hackers] [PATCH] find: Make parameter error messages more specific

Differenciate option operands from path operands when an error is detected on the command line parameters. --- find.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/find.c b/find.c index d4d7864..ef28232 100644 --- a/find.c +++ b/find.c @@ -809,8 +809,12 @@ parse(int

[hackers] [PATCH 2/2] scripts: Fix non-portable find -perm /mode

--- scripts/mkproto | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/mkproto b/scripts/mkproto index ab0ade4..192fe56 100755 --- a/scripts/mkproto +++ b/scripts/mkproto @@ -14,7 +14,7 @@ trap "rm -f scripts/proto" EXIT INT QUIT TERM (set -e echo d $prefix/bin

[hackers] [PATCH 1/2] scripts: Fix non-portable usage of find -maxdepth

--- scripts/mkproto | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/mkproto b/scripts/mkproto index 0b2deb3..ab0ade4 100755 --- a/scripts/mkproto +++ b/scripts/mkproto @@ -14,11 +14,11 @@ trap "rm -f scripts/proto" EXIT INT QUIT TERM (set -e echo d $prefix/bin

[hackers] [PATCH] scripts: Force file copying on install

This would otherwise cause an issue using cp to copy cp to itself. --- scripts/install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/install b/scripts/install index b391715..ce78c1d 100755 --- a/scripts/install +++ b/scripts/install @@ -9,7 +9,7 @@ do

[hackers] [PATCH] make: fix rogue parameter in install target

--- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 8da0106..95bb21d 100644 --- a/Makefile +++ b/Makefile @@ -219,11 +219,11 @@ getconf.h: scripts/getconf.sh > $@ install uninstall: - scripts/mkproto $@

Re: [hackers] [libgrapheme] Apply clang format || Laslo Hunhold

> Apply clang format Those are quite ugly > diff --git a/src/bidirectional.c b/src/bidirectional.c > index 6062ed6..9f1812c 100644 > --- a/src/bidirectional.c > +++ b/src/bidirectional.c > @@ -1400,8 +1400,8 @@ preprocess(HERODOTUS_READER *r, enum > grapheme_bidirectional_direction

Re: [hackers] [slstatus] More LICENSE updates || drkhsh

> > Would prefer just NRK :) > > And as far as I'm aware, using pseudonames for copyright should be > > fine. > > Would you use your pseudonym on a contract to buy a house? Would you steal a policeman's helmet and go to the toilet in it?

Re: [hackers] DWM keypad navigation?

> Hello there. Hi fossy, > Does anyone know if there's a way to use the key-pad numbers (usually > found on the right side of generic keyboards) to navigate tags? > > I'm sure it can be done.. > The default is XK_1, for example, using TAGKEYS() macro. The keypad keys are prefixed with XK_KP

Re: [hackers] [surf][PATCH 2/2] webext: use flags for gio-unix rather than gio

> Newly used g_unix_fd_* set of functions is from gio-unix. This corrects > the flags appropriately. I'm less inclied to applying this one though. In any case, gpio is needed and we shouldn't replace it. On my system, gio-unix symbols are provided by the gio library, is that different on your

Re: [hackers] [surf][PATCH 1/2] webext: add missing gio/gunixfdlist.h includes

Hi Petr, > This resolves two set of warnings pointed by compiler > -Wimplicit-function-declaration and -Wint-conversion, where the later > one can result with segfault caused by invalid cast from int to pointer. Thanks. What is strange is that on my system, gunixfdlist.h is just included from

Re: [hackers] [libgrapheme] Remove superfluous printf-parameter from the example || Laslo Hunhold

> Remove superfluous printf-parameter from the example > > This fortunately has no functional effect, it's just redundant. Like this sentence above. ;p

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

> >> >I think that the cast here is actually unnecessary, isn't it? > >> > >> No, because FcChar8 is unsigned, but the default signedness of char may be > >> either way. > > > >And? FcNameParse will use whatever is passed > >as a pointer to an unsigned char. > > With GCC 12.1.1 and our

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

> I beg to differ when the code declares something const but later then decides > >The constness is “maintained” here, the function gets a "const FcChar8 *" > > That's quite different: the code passes it a FcChar8* which it then treats as > a > const FcChar8*. Case in point, GCC 12.1.1 and

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

Hi Laslo, > I agree here. Not only should const be used to at least have a partial > "contract" for the function parameters (C doesn't offer a lot in this > regard and it's an easy way to prevent problems), The contract is respected, the function will not modify the variable pointed to by the

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

> Hi Quentin, Hey Cris, > In general the existing code seems confused, no? A code isn't confused, the reader might be though. Is there something you are not actually understanding here? > Either we shouldn't pass them in as const in the first place, > or we should maintain the constness that

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

Hi Cris, > I originally sent these a few years ago and the reply was that > const-correctness wasn't something cared about, but seeing other const > changes in dwm, and purely const-correctness improvements in > quark/st/libgrapheme, I figured maybe it's worth reevaluating and seeing > if they

Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

Hi NRK, --- dwm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dwm.c b/dwm.c index 253aba7..55dd68c 100644 --- a/dwm.c +++ b/dwm.c @@ -1808,7 +1808,8 @@ updatebars(void) .background_pixmap = ParentRelative, .event_mask =

Re: [hackers] [dwm] Revert "do not call signal-unsafe function inside sighanlder" || Hiltjo Posthuma

> Hi, Hi, > I could not find this specification in the POSIX standard, but [2] > says: > > POSIX.1-2001 specifies that if the disposition of SIGCHLD > is set to SIG_IGN or the SA_NOCLDWAIT flag is set for SIGCHLD > (see sigaction(2)), then children that terminate do not

Re: [hackers] [lsw] [PATCH] Improve compliance with our coding style

Hi Tom, > - if (!XGetTextProperty(dpy, win, , netwmname) || prop.nitems == 0) > - if (!XGetWMName(dpy, win, ) || prop.nitems == 0) > + if (!XGetTextProperty(dpy, win, , netwmname) || !prop.nitems) { > + if (!XGetWMName(dpy, win, ) || !prop.nitems) >

Re: [hackers] [sent] [PATCH 3/3] Makefile: config.mk: Improve Makefile and config.mk

> Hi Quentin, Hi Tom o/ > > > # includes and libs > > > -INCS = -I. -I/usr/include -I/usr/include/freetype2 -I${X11INC} > > > -LIBS = -L/usr/lib -lc -lm -L${X11LIB} -lXft -lfontconfig -lX11 > > > +INCS = -I/usr/include/freetype2 -I${X11INC} > > > +LIBS = -lm -L${X11LIB} -lXft -lfontconfig -lX11

Re: [hackers] [sent] [PATCH 3/3] Makefile: config.mk: Improve Makefile and config.mk

Hi Tom, > Let the Makefile be a bit more verbose and remove unnecessary extensions > and flags in config.mk. > --- > cscope: ${SRC} config.h > @echo cScope > - @cscope -R -b || echo cScope not installed > + cscope -R -b || echo cScope not installed I think that you can also

Re: [hackers] [libgrapheme] Explicitly use object-files in library-generation || Laslo Hunhold

Hi, > libgrapheme.a: $(SRC:=.o) > - $(AR) rc $@ $? > + $(AR) rc $@ $(SRC:=.o) > $(RANLIB) $@ This works as intended with $?, because then you only update objects that are out of date, not *all* objects inconditionally (just note that you might want the -u flag too).

Re: [hackers] [dwm][PATCH] preserve clients on old tags when renewing dwm

Hey Arda, > > I am really sorry, this is my first time posting a patch. I thought this > > list was for patches and mainstream both. I wanted to send this as a patch, > > where should I redirect this? > > I will redirect it to Wiki again, I have misread the website. Sorry for the > inconvenience.

Re: [hackers] [dwm][PATCH] preserve clients on old tags when renewing dwm

Hi Arda, I like the idea, thanks for the work. I'm not sure it really should be merged into the main repository though, a Window Manager doesn't have the purpose of being restarted on the fly, besides for debugging/testing purposes. Maybe it would have a better place in the patches section?

Re: [hackers] [sbase][PATCH] tar: support extracting long paths, link targets, and times.

Hi Andrew, > Posix tarballs use extended headers to represent paths and values that do > not fit in the original ustar header format. This patch implements parsing > and handling of a subset of these extended headers. The motivating > tarball was the gcc source code, which exceeds the original

Re: [hackers] [dwm|dmenu|st][PATCH] strip the installed binary

Hi Hiltjo, > I don't like this. > > I'd rather have it so the Makefile respects the system or package system > CFLAGS > and LDFLAGS by default. Then someone can do: make CFLAGS="-Os" LDFLAGS="-s" > etc. > > LDFLAGS="-s" is practically the same as calling strip and stripping it. > > It is up

Re: [hackers] [dwm|dmenu|st][PATCH] strip the installed binary

> Hi, Hi NRK, > Attached patches to strip the binary on installation for dwm, dmenu and > st. Looks good to me, thanks!

Re: [hackers] [dmenu] fix incorrect comment, math is hard || Hiltjo Posthuma

Hi Hiljto, > fix incorrect comment, math is hard diff --git a/dmenu.c b/dmenu.c index 571bc35..3595267 100644 --- a/dmenu.c +++ b/dmenu.c @@ -673,7 +673,7 @@ setup(void) mw = wa.width; } promptw = (prompt && *prompt) ? TEXTW(prompt) - lrpad / 4 : 0; -

Re: [hackers] [libsl|dmenu][PATCH v2] Fix truncation issues and improve performance

> On Mon, Mar 28, 2022 at 05:57:48PM +0600, NRK wrote: > > And on the topic of ellipsis_width, we currently don't account for > > fallback font: > > > > usedfont = drw->fonts; > > drw_font_getexts(usedfont, "...", 3, _width, NULL); > > > > The assumption here was that every font should

Re: [hackers] [libsl|dmenu][PATCH v2] Fix truncation issues and improve performance

> Hi, Hi NRK, > Fixed a couple bugs/issues with the previous patches and attached the > amended ones. I'm confident that these patches shouldn't have any > remaining logic issues, but feel free to point them out in case there is. > Additionally, there's one *new* patch attached, which fixes the

Re: [hackers] [sbase][PATCH] flock: call exec without forking

> Don't believe the '-F' flag is portable so avoided trying to add > it. flock(1) itself isn't portable, so none of its flag are.

Re: [hackers] [st][PATCH] Fix truecolor being slightly inaccurate

Hi Yutao, > The displayed color in truecolor mode is sometimes darker than > requested. The inaccuracy can be verified with the following example, > which should paint a white block but instead produces color #fefefe. > > printf '\e[38;2;255;255;255m\u2588\u2588\u2588\n' I get #ff on

Re: [hackers] st][PATCH - proper escape sequence for CTRL+HOME

Hi again Dave, > > Let that be a poor lesson for everybody, to you that coming to > > unfamiliar people with a negative attitude usually draws negative > > attitude in response. > > Nothing was wrong with my comment. You just chose to interpret it poorly--for > selfish reasons. Allright, but

Re: [hackers] st][PATCH - proper escape sequence for CTRL+HOME

Hi Dave, > It's not the language that's the problem, it's the piss-poor attitude. > > At first, I thought his response might have been a fluke. But then after > reading the other extremely rude comments made in response to mine, it seems > this is a group of extremely toxic people who are

Re: [hackers] [dwm][PATCH] Added support for RTL languages (Farsi, Arabic and Hebrew using the FriBiDi library)

Hi Mahdi, > hello sir, thank you I wanted this to be in the wiki, should I write a wiki > for the patch and send it over as markdown? or someone from the team does it > themselves? The wiki is open, you can push yourself your changes. Information can be found here: http://suckless.org/wiki/

Re: [hackers] [dmenu] revert using strcasestr and use a more optimized portable version || Hiltjo Posthuma

> revert using strcasestr and use a more optimized portable version > > ... compared to the old cistrstr(). I confirm that it's an improvement on my musl/Linux to both the old master code and reverted patch. Thanks Hiltjo!

Re: [hackers] [dmenu] follow-up fix: add -D_GNU_SOURCE for strcasestr for some systems || Hiltjo Posthuma

Hola, Here are my two cents, > On Mon, Feb 07, 2022 at 10:41:58AM +0100, Laslo Hunhold wrote: > > On Mon, 7 Feb 2022 10:36:46 +0100 (CET) > > g...@suckless.org wrote: > > > > Dear Hiltjo, > > > > > follow-up fix: add -D_GNU_SOURCE for strcasestr for some systems > > > > wouldn't it be

Re: [hackers] [libgrapheme] Refactor Makefile, add dist-target and add test-util || Laslo Hunhold

Hi Laslo, As a note, > -GEN = gen/grapheme gen/grapheme-test > -LIB = src/grapheme src/utf8 src/util > -TEST = test/grapheme test/grapheme-performance test/utf8-decode > test/utf8-encode > - > -MAN3 = man/lg_grapheme_isbreak.3 man/lg_grapheme_nextbreak.3 > +GEN =\ > + gen/grapheme\ > +

Re: [hackers][st][PATCH] Add support for OSC color sequences.

Hi Raheman, Just from a coding standpoint, > diff --git a/config.def.h b/config.def.h > index 6f05dce..91ab8ca 100644 > --- a/config.def.h > +++ b/config.def.h > @@ -120,6 +120,8 @@ static const char *colorname[] = { > /* more colors can be added after 255 to use with DefaultXX */ >

Re: [hackers] [sbase][PATCH] nohup: Open nohup.out WRONLY

Hi Arthur, > Open nohup.out write-only instead of not specifying the access permissions > instead of getting undefined behavior (which probably results in stdout > not being writable). > > - if ((fd = open("nohup.out", O_APPEND | O_CREAT, S_IRUSR | > S_IWUSR)) < 0) > +

Re: [hackers] [surf][patch] Use signed chars for webext messages.

Hello Noah, > Plain chars are currently used for messaging, but sometimes negative values > are sent, e.g. in scrollv. on x86 this doesn't cause a problem but chars are > unsigned on my arm computer. Thanks, I'll apply that soon.

Re: [hackers] [PATCH] Add a configuration option for fullscreen locking

> Hey folks, Hello Cris, > Looking at the conversation, it seems like the concern is about interaction > with the fakefullscreen[0] patch, if I understand correctly. No it's not.

[hackers] [PATCH] Add a configuration option for fullscreen locking

Some people are annoyed to have this new behaviour forced for some application which use fake fullscreen. --- config.def.h | 1 + dwm.c| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/config.def.h b/config.def.h index 1c0b587..a2ac963 100644 --- a/config.def.h +++

Re: [hackers] dvtm: add a comma at the end of kf22 entry in dvtm.info

Hi Greg, > > I see. I wrote to this list because of these instructions from > > https://github.com/martanne/dvtm: "If you have comments, suggestions, > > ideas, a bug report, a patch or something else related to dvtm then write > > to the suckless developer mailing list or contact me

Re: [hackers] [quark] http: fix default index serving

> Dear Quentin, > > I took a look at the archives[0] and have merged it in [1], however, > changed it into an else-case (to make it not depend on the fallthroughs > in the if only) and changed the mime-check so the mime-type is matched > against the docindex-path. I would prefer that you keep

Re: [hackers] [quark] http: fix default index serving

bump

[hackers] [quark] http: fix default index serving

The previous code would find and stat the default index file, but would not append it to the file served, resulting in giving back a 0-length content but with a Content-Length header of the size of the index. --- http.c | 5 + 1 file changed, 5 insertions(+) diff --git a/http.c b/http.c

Re: [hackers] [tabbed][PATCH] Remove quotes around variables from commands

> From: Sebastian LaVine Hi Sebastian, > Previously, if you had changed your PREFIX in config.mk to something > like ~/.local, then instead of installing to /home/user/.local, a > directory called '~' would be created in the project directory. Commands > are also performed without quotes in the

Re: [hackers] [dmenu][PATCH 0/2] New option for floating window

> Regarding the second one, I think you could put it on the wiki. Oh and I forgot, you should test in on displays with several monitors if you can!

Re: [hackers] [dmenu][PATCH 0/2] New option for floating window

Hello Jérémy, Thank you for you patches. > Those 2 patches allows to have dmenu displayed in a pop-up window in the > middle of the screen. Personally I like the way it looks and I think > that this option (-fw) could be available for everyone. I'll comment both here as these are general

Re: [hackers] [quark] Prevent overflow in strtonum()-parameters || Laslo Hunhold

> Make sure not to overflow the long long value. Given the standard > doesn't bring any tangible guarantees for the upper limits of size_t, SIZE_MAX is the tangible guarantee for the upper limit of size_t.

Re: [hackers] [dmenu][PATCH] Vim-like vertical and horizontal keybindings

> From: Spenser Truex Hello Spenser, Thanks for the patch, a few comments : Throughout the patch, there are indentation issues. > Ensure that the keybindings are like vim, and not just made up. This should be rephrased, precising that it's about vertical mode, and nothing is made up. > Old

Re: [hackers] [dmenu] bump version to 5.0 || Hiltjo Posthuma

> bump version to 5.0 \o/

Re: [hackers] [svkbd] Update Makefile

Hello Job, > 'make clean' now removes config.h Wrong > 'make dist' should no longer exit with error code 1 Good

Re: [hackers] [sbase] install: Use fchown to change owner || Michael Forney

> >> + if (fchown(f2, owner, group) < 0) > >> + eprintf("lchown %s:", s2); > > > > Little typo here ^ > > Whoops, missed that. In the follow up commit, I used the correct > function name, so I think it's just a mistake from when I split my > changes into two commits. Oh right,

Re: [hackers] [sbase] install: Use fchown to change owner || Michael Forney

Hi Michael, > + if (fchown(f2, owner, group) < 0) > + eprintf("lchown %s:", s2); Little typo here ^

Re: [hackers] [PATCH] tar: if first argument doesn't have a leading dash, prepend one

> > At least, I would print a warning if the old style syntax is seen so > > people start fixing their scripts. > > On what basis are scripts written to the SUSv2 specification broken? On the basis that tar was already specified as deprecated in SUSv1 26 years ago, and that sbase follows last

Re: [hackers] [PATCH] tar: if first argument doesn't have a leading dash, prepend one

> Every other tar implementation I've looked at supports either both > dash-less argument, and arguments with dashes, or only dash-less > argument. sbase tar is the only tar that only supports arguments with a > dash, so to use tar as portably as possible, one has to not have a dash > with the

Re: [hackers] [PATCH] tar: if first argument doesn't have a leading dash, prepend one

Hi all, > Dear Michael, > > > Thanks for the patch, Ethan. > > > > This patch looks fine to me, but seeing as we used to support this > > usage before it was reverted in [0], I'd like to see if anyone else > > has comments. The approach you used avoids the code duplication that > > may have

Re: [hackers] [scroll] Remove ^E and ^Y || Roberto E. Vargas

> - {"\031",SCROLL_UP,1}, /* mouse wheel up */ > - {"\005",SCROLL_DOWN, 1}, /* mouse wheel Down */ > + //{"\031",SCROLL_UP,1}, /* mouse wheel up */ > + //{"\005",SCROLL_DOWN, 1}, /* mouse wheel Down */ Did you

Re: [hackers] [dwm][patch] Fix transparent borders

> Hi, Hi Jakub, > Commit: > Please simply attach patches to email directly instead of redirecting to third-party prodivers/protocols.

Re: [hackers] [scroll] Dereference pointers || Jochen Sprickerhof

Hi Jochen, > Dereference pointers > - if (x <= 0 || y <= 0) > + if (*x <= 0 || *y <= 0) > die("invalid cursor position: x=%d y=%d", x, y); /--^--^ Here too :)

Re: [hackers] [scroll] Catch invalid cursor positions || Jochen Sprickerhof

> gcc emits this warning when using the "-Wextra" option. Should x and y be > dereferenced? yes

Re: [hackers] [scroll] Fix make on OpenBSD || Jochen Sprickerhof

> Sure, provide a patch to OpenBSD ;). Glad that you agree. The point is that this is not the correct place to fix this issue. > Does it break anything this way? It might break reader's understanding about how make works.

Re: [hackers] [scroll] Fix make on OpenBSD || Jochen Sprickerhof

> Fix make on OpenBSD > > -scroll: config.h > +scroll: scroll.c config.h I think it'd be better to fix OpenBSD make or let OpenBSD port maintainers to patch the software rather than pushing changes do standard code because of some buggy implementations.

Re: [hackers] [scroll] Rework the Makefile a bit || Quentin Rameau

Hey Jochen, Thanks for applying!

[hackers] [scroll][PATCH 1/2] Rework the Makefile a bit

--- Makefile | 18 -- config.mk | 13 ++--- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/Makefile b/Makefile index 4677e7a..c3e1c50 100644 --- a/Makefile +++ b/Makefile @@ -1,20 +1,21 @@ -include config.mk +.POSIX: -.PHONY: all clean install test

[hackers] [scroll][PATCH 2/2] Add distclean make target

--- Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index c3e1c50..4d415b7 100644 --- a/Makefile +++ b/Makefile @@ -4,9 +4,6 @@ include config.mk all: scroll -clean: - rm -f scroll ptty - config.h: cp config.def.h

Re: [hackers] [st][PATCH] Rearrange x run with fast exit

18, 2020 at 02:10:36PM +0100, Quentin Rameau wrote: > >> Quickly swap out of loop to reduce indentation needed. > >> Reuse deltatime variable to reuse calculation. > > > >Don't be afraid to separate unrelated modifications into separate > >commits! > > >

Re: [hackers] [st][PATCH] Rearrange x run with fast exit

> Quickly swap out of loop to reduce indentation needed. > Reuse deltatime variable to reuse calculation. Don't be afraid to separate unrelated modifications into separate commits!

Re: [hackers] [PATCH][sbase] paste: Allow null delim

> This has nothing to do with getopt(). This is about how the shell parses > and splits words into arguments. -d"" Erf of course, put that on the fever. ^^

Re: [hackers] [PATCH][sbase] paste: Allow null delim

On Thu, 5 Mar 2020 01:42:37 -0800 Michael Forney wrote: > On 2020-03-05, Quentin Rameau wrote: > >> Looking at POSIX, I see that `-d '\0'` must be supported, `-d ""` > >> is unspecified > > > > I don't think so, -d "" is just a list wit

Re: [hackers] [PATCH][sbase] paste: Allow null delim

Hello all, > Looking at POSIX, I see that `-d '\0'` must be supported, `-d ""` is > unspecified I don't think so, -d "" is just a list with an empty string. So -d '\0' is equivalent to -d '', '\0' is here to let the user express an empty string in a list, which wouldn't be possible otherwise

[hackers] [PATCH-v2] od: set -tx default byte number to integer size

Scratch the above patch, I forgot to credit prez for the report. Please use the attached patch! Thanks Michael >From f3eef8e9c4820b7764a229fa40d714f52fc676ee Mon Sep 17 00:00:00 2001 From: Quentin Rameau Date: Wed, 4 Mar 2020 17:02:15 +0100 Subject: [PATCH] od: set -tx default byte num

[hackers] [PATCH] od: set -tx default byte number to integer size

--- od.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/od.c b/od.c index 0b1c5c6..9ff8ff2 100644 --- a/od.c +++ b/od.c @@ -212,7 +212,7 @@ main(int argc, char *argv[]) { int fd; struct type *t; - int ret = 0, len; + int ret = 0, len,

Re: [hackers] [sbase][PATCH] od: Fix argument parsing for -t flag

Hi prez, > when the -t flag is used without a number of bytes, od exits with > usage(). 'od -tx foo' should behave like 'od -tx4 foo'. Indeed, > --- > od.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/od.c b/od.c > index 0b1c5c6..1780710 100644 > ---

Re: [hackers] [sbase] [PATCH] *sum: Ignore -b and -t flags

Hi Laslo, > > These tools are not standardized, but these flags are supported in all > > implementations I'm aware of (coreutils, busybox), and are > > occasionally used in scripts. > > > > These flags are only meaningful on operating systems which > > differentiate between text and binary

Re: [hackers] [sbase] libutil/recurse: Use while-loop instead of for-loop with only condition || Michael Forney

> Author: Michael Forney Hi Michael, > libutil/recurse: Use while-loop instead of for-loop with only condition The patch itself shows that, could you explain what it fixes or improve in your commit messages? Thanks. > diff --git a/libutil/recurse.c b/libutil/recurse.c > index

Re: [hackers] [dwm][PATCH] cleanup, saves 7 LOC

> As of [0], the Xorg man page for XFree reads: > > "If data is NULL, no operation is performed." > > It was changed to reflect the behavior that Xorg has always had. > XFree() has been #defined to free() since their initial code import in > 2003. However, it looks like other documentation was

Re: [hackers] [sbase] yes: Simplify, only support one argument || Michael Forney

> yes: Simplify, only support one argument > > The previous code was too difficult to decipher for such a simple tool. Agreed!

Re: [hackers] [sbase] Add .gitignore || Michael Forney

> > yuck > > Remarks like this aren't constructive, please keep them to yourself. Come on, don't be butthurted. > I already justified why adding .gitignore and rule to regenerate it is > useful. I'm sorry that you don't approve, but not having a .gitignore > was a significant annoyance to me

Re: [hackers] [sbase] Add .gitignore || Michael Forney

> Add .gitignore > > Also, add rule to regenerate in case executable list changes. yuck

Re: [hackers] [sbase][PATCH] Minor optimizations for 'yes'

> Dear Quentin, Hi Laslo, > > I agree, yes is neither a benchmark tool nor a data generator, it just > > outputs 'y' for piping into other commands. > > Keep it simple. > > I agree with you in general, but are we really "optimizing" yes(1) here > for the sake of performance? This looks to me

Re: [hackers] [sbase][PATCH] Minor optimizations for 'yes'

Hello, > So, we could make this as simple as > > s = argc > 1 ? argv[1] : "y"; > for (;;) > puts(s); > > >> I think I'd prefer > >> > >>for (;;) > >>puts("y"); > >> > >> here. > > Originally, I had a puts(3) call there, but this decreased the

Re: [hackers] [sbase] [PATCH] Add .gitignore

> On 2019-06-17, Quentin Rameau wrote: > >> How do you deal with ~250 lines of "Untracked files:" in the `git > >> status` output? > >> > >> If you want to see them, you can always run `git status --ignored`. > > > > If you want it, you

Re: [hackers] [sbase] [PATCH] Add .gitignore

On Mon, 17 Jun 2019 13:40:47 -0700 Michael Forney wrote: > On 2019-06-17, Quentin Rameau wrote: > >> What's the downside to having it checked into the repository? Are > >> there any reasons why a user wouldn't want this feature? Personally, I > >> want it in ever

Re: [hackers] [sbase] [PATCH] Add .gitignore

> > I'm not really keen on pushing this file to the source history, I think > > this should be kept separate, this is a user-side feature. > > What's the downside to having it checked into the repository? Are > there any reasons why a user wouldn't want this feature? Personally, I > want it in

Re: [hackers] [sbase] [PATCH] Add .gitignore

Hello Michael, > Also, add rule to regenerate in case executable list changes. > --- > Any objection to this? I'm not really keen on pushing this file to the source history, I think this should be kept separate, this is a user-side feature. But having a rule un the Makefile, as you did, is a

Re: [hackers] [sbase] [PATCH] libutil: Rename functions in reserved namespace to prevent potential conflict

> strsep is reserved. > > C11 standard section 7.30 Future library directions: > > The following names are grouped under individual headers for > convenience. All external names described below are reserved no matter > what headers are included by the program. > > 7.30.10 String handling > >

Re: [hackers] [sbase] [PATCH] libutil: Rename functions in reserved namespace to prevent potential conflict

> libc may define functions with the same names, but differing in prototype. > --- > Anyone have any comments on this patch before I push it? > > The motivating conflict is with strsep, which glibc declares as > > char *strsep(char **restrict, const char *restrict); > > which is not

Re: [hackers] [dwm][PATCH] hide_vacant_tags patch

On Fri, 29 Mar 2019 15:32:19 +0100 Ryan Kes wrote: > --- > dwm.c | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) Hello Ryan, You can update those patches yourself, I suggest having a look at http://suckless.org/wiki/

Re: [hackers] [st][patch] be silent about explicitly unhandled mouse modes

Hello Abdullah, > it fixes this. > > see attachment. > > On 13/03, Quentin Rameau wrote: > > Hello Lauri, > > > > > diff below fixes it. > > > > What does it fix? > > Please do not send to this mailing list while being drunk.

Re: [hackers] [st][patch] be silent about explicitly unhandled mouse modes

> the erroneous output on stderr. the comment reads like these escapes are > intentionally left unhandled, but in that case it doesn't make sense to > output an error about them. Ok, I thought there was actually an issue preventing tmux to work correctly.

Re: [hackers] [st][patch] be silent about explicitly unhandled mouse modes

Hello Lauri, > diff below fixes it. What does it fix?

Re: [hackers] [dev][slstatus] FreeBSD port?

> Hi, Hi Michael, > As part of my setup of FreeBSD I ported slstatus. Is the mainline a place > to commit such patches given the platform dependence of a tool like > slstatus? I guess porting to new platforms can increase the size of the > code base significantly if one sticks to the current

Re: [hackers] Re: [st][patch] Refresh keyboard mapping

> > Interesting but I can't reproduce any issue with that, could you > > provide a way to raise a problem this way? > > Expect it within 24 hours. Ok, I started the (final) countdown.

  1   2   >