Sent with Proton Mail secure email.
On Friday, September 6th, 2024 at 1:23 PM, Страхиња Радић
wrote:
> Дана 24/09/06 07:33PM, Brandon Pribula написа:
>
> > If the change to the man pages is acceptable I'm happy to submit the
> > changes in whatever fashion.
>
>
> Please read the entire
Дана 24/09/06 07:33PM, Brandon Pribula написа:
> If the change to the man pages is acceptable I'm happy to submit the
> changes in whatever fashion.
Please read the entire
https://suckless.org/hacking
Hello,
When viewing sbase's man pages the date displayed at the bottom is the current
date rather than the date entered in the .1 file.
According to this:
https://mandoc.bsd.lv/mdoc/details/date.html
the traditional man date format used by sbase (.Dd year-month-day) is no longer
recommended a
On 2024-03-14 11:49, Roberto E. Vargas Caballero wrote:
The idea is that everything is portable. Let's take the example of
ps. We can extract the non portable bits of ps into the libsys
library (or whatever name we like), so the code in posix/ is portable.
Ok, that is evidently better. Having
Hi,
On Wed, Mar 13, 2024 at 11:51:46PM +0100, Elie Le Vaillant wrote:
> I think this layout has a few problems:
>
> - we lose the meaningful separation that the sbase/ubase layout allowed,
> i.e the distinction
> between what is portable and what isn't. This _could_ be included as
> part of
On 2024-03-13 11:27, Roberto E. Vargas Caballero wrote:
I am thinking about the new layout, and for now I was considering
something like:
- posix (tools defined by POSIX)
- misc (helpful tools not defined by POSIX).
- linux (tools that only make sense in linux)
- curses-
Hi,
I have pushed a new branch called ubase-merge that has all
the files from ubase in the directory ubase of the root directory
in the repository. You can still see the full history of a file
in that directory using something like git log --follow.
I am thinking about the new layout, and for now
Hi,
After reading the opinion of the people in this thread,
I think the best option is to merge the sbase and ubase
repositories and having a mechanism in the build system
to select the set of tools to be included in the build.
The main drawback of this is that the build system will
be more comple
> Everything in the quoted part seems personal preference.
I've been managing my vim plugins with git submodules via vim's builtin
"packadd" directory structure (~/.config/vim/pack/plugins/start/...).
And I can tell you that trying to do anything remotely non-trivial with
them is simply not a plea
On Sat, 09 Mar 2024 17:28:49 +0100
Elie Le Vaillant wrote:
> Страхиња Радић wrote:
> > Compiling all programs into one binary is currently an option, and IMHO it
> > should remain an option.
>
> I fully agree. However, the single binary situation should be improved.
>
> > Great, combine the
On 24/03/09 05:28PM, Elie Le Vaillant wrote:
> Or is it out-of-scope for us to implement a full-blown shell? I really am
> not sure.
I think it would be interesting to have "official" suckless versions of all of
the mentioned programs, which would at minimum implement their descriptions
from POS
Страхиња Радић wrote:
> Compiling all programs into one binary is currently an option, and IMHO it
> should remain an option.
I fully agree. However, the single binary situation should be improved.
> Great, combine the two versions of libutil into a single, separate
> libutil repository
I'm no
On Sat, 9 Mar 2024 14:53:07 +0100
Страхиња Радић wrote:
> On 24/03/09 12:59AM, Mattias Andrée wrote:
> > I agree, a single repo (or alternatively making libutil it's own repo) is
> > necessary if we want one binary, and I think we do.
>
> Compiling all programs into one binary is currently an
On 24/03/09 12:59AM, Mattias Andrée wrote:
> I agree, a single repo (or alternatively making libutil it's own repo) is
> necessary if we want one binary, and I think we do.
Compiling all programs into one binary is currently an option, and IMHO it
should remain an option. In my own toy distro[1]
On Sat, 09 Mar 2024 12:10:28 +0100
Eolien55 wrote:
> Mattias Andrée wrote:
> > I think there should be one directory called "portable" containing only
> > tools
> > from sbase, and one directory called "linux" containing the tools from ubase
> > and maybe even symlinks to the tools in "portable
Mattias Andrée wrote:
> I think there should be one directory called "portable" containing only tools
> from sbase, and one directory called "linux" containing the tools from ubase
> and maybe even symlinks to the tools in "portable". This structure would allow
> us to add implementations for othe
On Fri, 08 Mar 2024 23:33:12 +0100
Eolien55 wrote:
> Страхиња Радић wrote:
> > The problem of having separate *box executables could be solved by creating
> > an
> > "umbrella" *box project, perhaps having sbase, ubase and
> > [insert_letter]base as
> > git submodules, and deciding what to b
Страхиња Радић wrote:
> The problem of having separate *box executables could be solved by creating
> an
> "umbrella" *box project, perhaps having sbase, ubase and [insert_letter]base
> as
> git submodules, and deciding what to build based on the contents of config.mk.
The problem is that sba
On 24/03/08 06:40AM, Roberto E. Vargas Caballero wrote:
> I would like to move the discussion here and see what alternatives
> we have and how to proceed in this case.
IMHO, if the intention behind sbase was to provide a minimal portable POSIX
utilities implementation, anything not fitting that d
I think we should keep the implementation of each tool as minimal as
possible, but POSIX-complete, and of course common tools such as
install(1) and tar(1). However, actually using a system that is
nothing more than POSIX is very cumbersome. And I think it is a better
solution to implement non-stan
Elie Le Vaillant wrote:
> Another idea could be to have both in the same git repository,
> [...]
This would be my idea as well. It also wouldn't be that difficult
to let people pick and choose which sets of tools to include in the
final -box via config.mk or similar. I would stick with only the
h
Hi,
I think one of the main current issues with the current
organization of sbase's and ubase's code, is that while
they share parts of code (some parts of libutil are shared),
they do not actually have it in common. As a result, changes
to shared parts of libutil in sbase are not reflected in uba
Hi,
While reviewing several patches for sbase adding new tools
some discussion happened and I thought it was better to move the
discussion here.
The patches raised a concern about what should be the scope of
sbase. The idea of sbase was to provide a minimal portable POSIX
base, while having ubase
I noticed that 'tar' is very slow to compress if compared to 'GNU
tar', especially when there are multiple small files.
26 GB of OS's ISO images:
GNU tar: 195s
sbase tar: 250s
(128% more)
3.6 GB of images:
GNU tar: 3s
sbase tar: 27s
(900% more) (!)
Hi,
On Mon, Jan 22, 2024 at 08:11:42PM +, ruivlea wrote:
> After sbase commits:
> - 270ca025ce236885e3177cd7acfd2cfbdf6e36a5
> expr: don't evaluate matched substr as a number
> - e50d533d598dbe284e225e2ee52ed5f76a6e6f6a
> expr: treat expressions as strs until evaluation
>
> I fail to buil
Hello,
After sbase commits:
- 270ca025ce236885e3177cd7acfd2cfbdf6e36a5
expr: don't evaluate matched substr as a number
- e50d533d598dbe284e225e2ee52ed5f76a6e6f6a
expr: treat expressions as strs until evaluation
I fail to build linux using sbase
due to expr segmentation fault:
Linux Makefile
On Thu, Jun 22, 2023 at 05:46:09PM +0100, Frank Busse wrote:
> Hi,
>
>
> I ran KLEE on revision #530407 and it found a segfault in cron. It can
> be reproduced via:
>
> $ printf '1*' > A
> $ sbase-530407/bin/cron "-nfA"
>
> Seems free() points into rubbish:
>
> AddressSanitizer:DEADLYSIGNAL
>
Hi,
I ran KLEE on revision #530407 and it found a segfault in cron. It can
be reproduced via:
$ printf '1*' > A
$ sbase-530407/bin/cron "-nfA"
Seems free() points into rubbish:
AddressSanitizer:DEADLYSIGNAL
=
==2103==ERROR: Addres
On Tue, 31 Jan 2023 14:05:05 +0100 (CET)
Andrea Calligaris wrote:
Dear Andrea,
> Do you think it should?
>
> I'm not interested in a short-term implementation, I'm more
> interested if you think that it should, or if you have an opinion
> against it. Im my opinion it should, because someone may
Do you think it should?
I'm not interested in a short-term implementation, I'm more interested if you
think that it should, or if you have an opinion against it.
Im my opinion it should, because someone may rely on hardlinks to manage its
data, and if you want to backup your stuff in a tar archiv
Whoops, I withdraw my complaint. Should have checked the basics before I
talked.
This is a packaging error. Sorry to waste your time and mine.
Regards,
spaceman
> Hi,
Hi Spaceman,
> When compiled with musl-gcc (latest) on Slackware 14.2 this:
>
> static void
> dowrite(const char *fname, int trunc)
> {
> …
> printf("%zu\n", bytecount);
> }
>
> does not work for me (it outputs a blank line). Given my rudimentary
> knowledge of C and looking up on
Hi,
When compiled with musl-gcc (latest) on Slackware 14.2 this:
static void
dowrite(const char *fname, int trunc)
{
…
printf("%zu\n", bytecount);
}
does not work for me (it outputs a blank line). Given my rudimentary
knowledge of C and looking up on stackoverflow this does work.
static
*** Hadrien Lacour [2020-11-25 19:27]:
>The tl;dr is that you either use POSIX ustar with its path length and file size
>limits, or use GNU tar when your input doesn't fit; pax was supposed to be the
>replacement, but is more or less unused/ignored.
In my opinion it is better to improve pax suppor
On Wed, 25 Nov 2020 22:49:32 +0100
Mattias Andrée wrote:
Dear Mattias,
> Concerning farbfeld, it is quite a different thing to create a new
> simpler standard than supporting an already existing but complex
> standard. Farbfeld was a good first step in moving towards simpler
> image formats, alt
On Wed, 25 Nov 2020 18:32:36 +0100
Thomas Oltmann wrote:
Dear Thomas,
> > if gnu tar proprietary?
>
> No. I think Laslo meant 'proprietary' as in 'ad hoc' or 'incompatible'
> (with standard implementations).
yeah, I used a pretty "drastic" word to describe it. All will agree
that GNU-tar is
Hi all,
Laslo Hunhold wrote:
> Dear Cág,
> Even if a suckless implementation of GNU tar was possible, would you
> really want it to be included? I'd rather like to encourage people to
> use standard non-proprietary file formats.
Yeah, I think I would. tar(1) is one of those cases where a comprom
> if gnu tar proprietary?
No. I think Laslo meant 'proprietary' as in 'ad hoc' or 'incompatible'
(with standard implementations).
> there's probably no way to implement those GNU-extensions in a good and
> suckless way. The FSF has the bad habit for their
> standard-implementations that they tend
On Wed, 25 Nov 2020 16:28:02 -0500
Cág wrote:
> Hi all,
>
> Laslo Hunhold wrote:
> > Dear Cág,
> > Even if a suckless implementation of GNU tar was possible, would you
> > really want it to be included? I'd rather like to encourage people to
> > use standard non-proprietary file formats.
>
>
if gnu tar proprietary?
Nov 25, 2020, 16:49 by d...@frign.de:
> On Wed, 25 Nov 2020 07:51:22 -0500
> Cág wrote:
>
> Dear Cág,
>
>> A quick question: for "POSIX tar archive (GNU)" files tar prints
>> tar: unsupported tar-filetype L
>>
>> Is GNU tar support out of scope?
>>
>
> there's probably
On Wed, Nov 25, 2020 at 05:49:56PM +0100, Laslo Hunhold wrote:
> On Wed, 25 Nov 2020 07:51:22 -0500
> Cág wrote:
>
> Dear Cág,
>
> > A quick question: for "POSIX tar archive (GNU)" files tar prints
> > tar: unsupported tar-filetype L
> >
> > Is GNU tar support out of scope?
>
> there's probably no
On Wed, 25 Nov 2020 07:51:22 -0500
Cág wrote:
Dear Cág,
> A quick question: for "POSIX tar archive (GNU)" files tar prints
> tar: unsupported tar-filetype L
>
> Is GNU tar support out of scope?
there's probably no way to implement those GNU-extensions in a good and
suckless way. The FSF has th
Hi,
A quick question: for "POSIX tar archive (GNU)" files tar prints
tar: unsupported tar-filetype L
Is GNU tar support out of scope?
Cheers
--
caóc
On 2020-03-22, Hiltjo Posthuma wrote:
> Maybe it's an idea to just place issues in a TODO file in the repository?
That's a good idea, thanks.
I added a section with the issues reported by Cág, some existing items
from ed.c, and a few others I have noticed.
Hi,
As the original author of ed I have to apologize about this kind
of errors. I didn;t have so much time to finalize it, and there is
a list of known bugs in the header of the file. I would recomend to
add new known bugs to the the list and them let to new people to
fix them. I think the code o
Michael Forney wrote:
> Sometimes people just don't have the time to investigate the issue and
> come up with a fix. It could even be that the fix involves more
> complex restructuring of the rest of the code.
Hello Michael,
Thanks for understanding. There's definitely a lack of time on my side
On Sat, Mar 21, 2020 at 05:01:05PM -0700, Michael Forney wrote:
> On 2020-03-21, Hiltjo Posthuma wrote:
> > What kind of tracker?
>
> Did you see my other reply?
> https://lists.suckless.org/dev/2003/33827.html
>
I didn't see it.
> >I think discussions of suckless projects should stay
> > on t
On Sat, Mar 21, 2020 at 02:59:12PM -0700, Michael Forney wrote:
> On 2020-03-17, Hiltjo Posthuma wrote:
> > Where is the patch?
>
> I know it's contrary to the opinion of a lot of people here, but
> personally, I have no issue with bug reports without a patch.
> Sometimes people just don't have t
On Sat, 21 Mar 2020 14:59:12 -0700
Michael Forney wrote:
Dear Michael,
> I know it's contrary to the opinion of a lot of people here, but
> personally, I have no issue with bug reports without a patch.
> Sometimes people just don't have the time to investigate the issue and
> come up with a fix.
On 2020-03-21, Hiltjo Posthuma wrote:
> What kind of tracker?
Did you see my other reply?
https://lists.suckless.org/dev/2003/33827.html
>I think discussions of suckless projects should stay
> on the mailinglist and/or IRC, not an external bugtracker or something.
Would suckless.org consider ho
On 2020-03-17, Hiltjo Posthuma wrote:
> Where is the patch?
I know it's contrary to the opinion of a lot of people here, but
personally, I have no issue with bug reports without a patch.
Sometimes people just don't have the time to investigate the issue and
come up with a fix. It could even be th
On Sat, Mar 21, 2020 at 03:02:04PM -0700, Michael Forney wrote:
> On 2020-03-17, Cág wrote:
> > There are a couple things I've come across the
> > sbase's version of ed:
> > 1. w doesn't print the byte count. Suppose a sample
> > ed session (using P to distinguish my input from ed's
> > output):
On 2020-03-17, Cág wrote:
> There are a couple things I've come across the
> sbase's version of ed:
> 1. w doesn't print the byte count. Suppose a sample
> ed session (using P to distinguish my input from ed's
> output):
> % ed
> P
> *a
> milk
> bread
> eggs
> meat
> veggies
> bananas
> apples
>
On Tue, Mar 17, 2020 at 11:25:25AM -0400, Cág wrote:
> I must admit I only use ed(1) (of sbase) these days.
> It has been like this for a year or so.
>
> There are a couple things I've come across the
> sbase's version of ed:
> 1. w doesn't print the byte count. Suppose a sample
> ed session (usi
I must admit I only use ed(1) (of sbase) these days.
It has been like this for a year or so.
There are a couple things I've come across the
sbase's version of ed:
1. w doesn't print the byte count. Suppose a sample
ed session (using P to distinguish my input from ed's
output):
% ed
P
*a
milk
bre
On 2020-01-17, Quentin Rameau wrote:
>> Perhaps we should bring this up on the austin group list and get them
>> to clarify the text.
>
> Done, let's wait and see.
Thanks, Quentin!
For anyone following, the clarification request is at
https://www.austingroupbugs.net/view.php?id=1319
> Perhaps we should bring this up on the austin group list and get them
> to clarify the text.
Done, let's wait and see.
On Fri, Jan 17, 2020 at 5:17 AM Michael Forney wrote:
>
> All the other implementations I looked at *do* insert the contents of the
> file.
I think that's the important point. We should also check how other
commands that "start the next cycle" behave in relation to r. E.g. I
could see the same p
> Hello,
Hi Michael,
> I recently ran into a package (dialog), which uses the following sed
> script to generate its dlg_config.h header:
>
> /@DEFS@/r conftest.frag
> /@DEFS@/d
>
> The intention is to replace @DEFS@ in the header template with the
> contents of a file. However, sbase sed skips
Hello,
I recently ran into a package (dialog), which uses the following sed
script to generate its dlg_config.h header:
/@DEFS@/r conftest.frag
/@DEFS@/d
The intention is to replace @DEFS@ in the header template with the
contents of a file. However, sbase sed skips writing the contents of
the fi
On Sat, 28 Dec 2019 16:24:57 -0800
Michael Forney wrote:
Dear Michael,
> I'm only proposing removing -H, -L, and -P from chmod, not the other
> tools. The only POSIX option is -R, and the only use I can think of
> for chmod -L is if you wanted to modify the permissions of files
> outside the dir
On 2019-12-23, Laslo Hunhold wrote:
> On Sat, 21 Dec 2019 19:05:45 -0800
> Michael Forney wrote:
>
> Dear Michael,
>
>> I can think of two possibilities here:
>>
>> 1. Remove the -H, -L, and -P options from chmod, always set r.follow =
>> 'H', and call chmod(3) conditional on !S_ISLINK(st->st_mod
On 2019-12-23 16:47:59 +0100, Laslo Hunhold wrote:
> [..] Especially with the H, L and P options we found many bugs in GNU
> coreutils, and keeping them in is essential if we want to claim that
> we are more or less POSIX compliant. [..]
Sorry I do not understand how this is meant. Looking at the
On Sat, 21 Dec 2019 19:05:45 -0800
Michael Forney wrote:
Dear Michael,
> I can think of two possibilities here:
>
> 1. Remove the -H, -L, and -P options from chmod, always set r.follow =
> 'H', and call chmod(3) conditional on !S_ISLINK(st->st_mode).
> 2. Keep the -H, -L, and -P options, but us
On Sat, Dec 21, 2019 at 07:05:45PM -0800, Michael Forney wrote:
> - Most BSD chmod(1) have -H, -L, and -P options (defaulting to -P),
> and the filesystem *does* record the mode of a symlink, but this mode
> has no affect on the kernel's access checks.
Well, most Linux FSes have the capacity to re
On 2019-11-03, Silvan Jegen wrote:
> I assume it's the leading whitespace that was the problem since here[0]
> the output format is given as
>
> "%d %d %d %s\n", , , ,
>
>
> Considering this and that [0] doesn't mention anything about alignment,
> just having "%zu %zu %zu %s\n" as before seems li
Hi,
I'm looking into improving chmod(1) behavior with symbolic links.
First, some background:
- The mode of symbolic links is not used anywhere, and on linux,
fchmodat(AT_FDCWD, path, mode, AT_SYMLINK_NOFOLLOW) on a symlink
returns EOPNOTSUPP.
- POSIX only specifies the -R option, and doesn't say
Hi
Michael Forney wrote:
> [...]
>
> This leaves issue 1, which makes me wonder about the point of the
> field widths if they aren't for alignment of the output. If we don't
> care about alignment, I think we should just use "%zu %zu %zu %s\n".
> If we do care about the alignment, we should use f
Hi,
I was looking through wc.c in sbase and noticed a couple curious
things about the output formatting. POSIX says the tool should write
"%d %d %d %s\n", , , ,
When the tool was first written, it used fixed field widths,
presumably to maintain alignment when multiple files were specifi
Since glibc 2.28, sys/types.h no longer includes sys/sysmacros.h which
defines the major and minor macros. Some BSDs don't have
sys/sysmacros.h, so sbase has been conditionally including
sys/sysmacros.h on glibc since 99c78763[0].
However, in the upcoming musl release, it too will remove the
sys/s
> having external programs link against libutil.a is a PITA because musl/glibc
> also have a libutil.a in the library directory. IMHO the name could be changed
> to something less general.
If you have musl/glibc libutil.a in sbase directory, you've got a real
problem indeed, but unrelated to this
Hi,
having external programs link against libutil.a is a PITA because musl/glibc
also have a libutil.a in the library directory. IMHO the name could be changed
to something less general.
On Mon, Oct 22, 2018 at 09:12:43PM +0200, Hiltjo Posthuma wrote:
> On Mon, Oct 22, 2018 at 08:18:43PM +0300, A
I was thinking it maybe has a generic name and could be splitted in
smaller, more specific, libraries?
On Mon, Oct 22, 2018 at 10:14 PM Hiltjo Posthuma wrote:
>
> On Mon, Oct 22, 2018 at 08:18:43PM +0300, Adrian Grigore wrote:
> > Is there any interest in splitting llibutil from sbase in smaller l
On Mon, Oct 22, 2018 at 08:18:43PM +0300, Adrian Grigore wrote:
> Is there any interest in splitting llibutil from sbase in smaller libraries?
> --
> Thanks,
> Adi
>
No, why?
--
Kind regards,
Hiltjo
Is there any interest in splitting llibutil from sbase in smaller libraries?
--
Thanks,
Adi
On Thu, 27 Sep 2018 at 11:06, Evan Gates wrote:
> On Wed, Sep 26, 2018 at 5:49 PM Tavian Barnes
> wrote:
> >
> > Hi! As the author of a find-compatible tool, whenever I find another
> > find implementation I run my testsuite against it to see if I find any
> > bugs in either one. sbase/find he
On Wed, Sep 26, 2018 at 5:49 PM Tavian Barnes wrote:
>
> Hi! As the author of a find-compatible tool, whenever I find another
> find implementation I run my testsuite against it to see if I find any
> bugs in either one. sbase/find helped me identify many places in my
> POSIX tests that use exte
Hi! As the author of a find-compatible tool, whenever I find another
find implementation I run my testsuite against it to see if I find any
bugs in either one. sbase/find helped me identify many places in my
POSIX tests that use extensions to POSIX when they shouldn't, so
thanks! Here's the bugs
Markus Wichmann wrote:
> Because ls's job is to list files. Not to columnate output. There's
> another tool for that.
Makes sense; there's cols(1) for that.
> Unfortunately, GNU ls is capable of outputting color codes, but BSD
> column is not capable of understanding them. I tried to write somet
On Thu, Jul 19, 2018 at 03:49:10PM -0400, Cág wrote:
> If you take a look at README (https://git.suckless.org/sbase/tree/README),
> you'll find out completeness of the programs and missing arguments; out
> of all I only wonder why multi-column output of ls(1) is intentionally
> left out. On Plan 9
If you take a look at README (https://git.suckless.org/sbase/tree/README),
you'll find out completeness of the programs and missing arguments; out
of all I only wonder why multi-column output of ls(1) is intentionally
left out. On Plan 9 it is one-column, too, though.
caóc
On Wed, Jul 18, 2018 at 06:32:57PM +0200, Markus Wichmann wrote:
> And that's where you're wrong. "find | xargs" is wrong for the same reason
> "sudo su" is wrong, for the same reason "cat singlefile | whatever" is
> wrong: You're doing it wrong. In your case "find -exec" does everything
> you want
On Tue, Jul 17, 2018 at 07:28:25PM -0700, Eric Pruitt wrote:
> The suckless tools don't strictly follow POSIX. For example, sbase mv(1)
> and cp(1) don't support "-i". Furthermore it's pretty portable; find(1)
> on OpenBSD, FreeBSD, macOS and GNU find(1) all support using NUL bytes.
> It's the only
On Tue, Jul 17, 2018 at 07:05:43AM -0700, Evan Gates wrote:
> find -print0 is not specified by POSIX. If you want to print nul
> separated data use:
The suckless tools don't strictly follow POSIX. For example, sbase mv(1)
and cp(1) don't support "-i". Furthermore it's pretty portable; find(1)
on O
On Sun, Jul 15, 2018 at 12:41 PM andremw wrote:
> -find /home/user -type d -print0 | xargs -0 chmod 0775
> -find /home/user -type f -print0 | xargs -0 chmod 0664
>
> In busybox they work, in sbase they return-
> -find: paths must precede expression: -print0
> -usage: xargs [-rtx] [-E eofstr] [-n n
> Hello friends.
Hello Andrew,
> I always used busybox but now I decided to use sbase because of the
> simplicity and lightweight.
Nice!
> I had a script to fix /home/user files and directories permissions that
> always worked on busybox but fails on sbase.
> I wonder if the programs in sbase
Hello friends.
I always used busybox but now I decided to use sbase because of the simplicity
and lightweight.
I had a script to fix /home/user files and directories permissions that always
worked on busybox but fails on sbase.
I wonder if the programs in sbase have a bug or if my commands aren't
On Fri, 16 Jun 2017 21:00:40 +0200
Quentin Rameau wrote:
> Hi,
>
> > Sounds like it says you must not write those error message if -f is
> > used. Kind of a strange requirement as `2>/dev/null` would do that.
> >
> > > I don't fully understand the wording in POSIX on the page[0].
> > >
> > >
Hi,
> Sounds like it says you must not write those error message if -f is
> used. Kind of a strange requirement as `2>/dev/null` would do that.
>
> > I don't fully understand the wording in POSIX on the page[0].
> >
> > [0]
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html
“
Sounds like it says you must not write those error message if -f is used.
Kind of a strange requirement as `2>/dev/null` would do that.
On Fri, 16 Jun 2017 20:14:58 +0200
Hiltjo Posthuma wrote:
> On Fri, Jun 16, 2017 at 02:08:24PM -0300, Marc Collin wrote:
> > Hello all.
> >
> > I found a case
On Fri, Jun 16, 2017 at 02:08:24PM -0300, Marc Collin wrote:
> Hello all.
>
> I found a case where sbase rm command fails but doesn't output any
> error message, making it look like it succeeded.
>
> mkdir ./test
> mkdir ./test/test
> sudo chown root:root ./test
> sudo chown root:root ./test/test
Hello all.
I found a case where sbase rm command fails but doesn't output any
error message, making it look like it succeeded.
mkdir ./test
mkdir ./test/test
sudo chown root:root ./test
sudo chown root:root ./test/test
rm -rf ./test
rm won't output anything and exit (apparently) cleanly.
But the
On 6/13/17, Mattias Andrée wrote:
> On Linux, the performance of cat(1) can be doubled
> when cat(1):ing from one pipe to another, by compiling
> with -DBUFSIZ=(1<<16) (the default pipe capacity).
> This is close to optimial for a read(3)/write(3)
> implementation.
Agreed. On my sbase branch, I b
9:18
To: dev@suckless.org
Subject: Re: [dev] [sbase] Changing BUFSIZ
Mattias Andrée wrote:
> On Linux, the performance of cat(1) can be doubled
> when cat(1):ing from one pipe to another, by compiling
> with -DBUFSIZ=(1<<16) (the default pipe capacity).
> This is close to optim
Mattias Andrée wrote:
> On Linux, the performance of cat(1) can be doubled
> when cat(1):ing from one pipe to another, by compiling
> with -DBUFSIZ=(1<<16) (the default pipe capacity).
> This is close to optimial for a read(3)/write(3)
> implementation.
I have seen people mentioning how is GNU y
On Linux, the performance of cat(1) can be doubled
when cat(1):ing from one pipe to another, by compiling
with -DBUFSIZ=(1<<16) (the default pipe capacity).
This is close to optimial for a read(3)/write(3)
implementation.
pgpKj3MyxJW0x.pgp
Description: OpenPGP digital signature
Hello everyone,
got a question about the tar implementation. Are the GNU-specific
filetypes headers meant to be supported? I'm thinking specifically about
the 'L' and 'K' types, respectively LongName and LongLink.
If there is any alternative to avoid implementing it, it'd be better IMO,
as it woul
Willy Gfn wrote:
> Michael Forney wrote:
> > On 12/24/16, Cág wrote:
> > > Markus Wichmann wrote:
> > >
> > >> Well, that looks like it might be problematic, doesn't it? Especially
> > >> when you find out, that the size of h->name there is 100 bytes. path
> > >> contains, of course, the entire fi
Michael Forney wrote:
> On 12/24/16, Cág wrote:
> > Markus Wichmann wrote:
> >
> >> Well, that looks like it might be problematic, doesn't it? Especially
> >> when you find out, that the size of h->name there is 100 bytes. path
> >> contains, of course, the entire file path relative to the startin
Michael Forney wrote:
> On 2/2/17, willy wrote:
> > At this point, I'm not sure where to look at, or even if the bug
> > really lies in tar and not in bzip2.
> > I checked the size (both octal and converted) and the value is good. So
> > I'm not sure why the headers are not well read.
> > In the c
1 - 100 of 1283 matches
Mail list logo
