Re: [dev] Replace ranlib(1) calls?

2022-08-01 Thread Roberto E. Vargas Caballero
Hi,

On Sun, Jul 31, 2022 at 01:00:23AM +0200, Laslo Hunhold wrote:
> I must admit that I only copied the ar-ranlib-invocation likewise from
> what I found on the internet for my libraries, so even though I don't
> think it makes any difference (i.e. increases portability apart from
> standards-legalese), it helps to make ranlib more and more superfluous
> and promote the best practice, which is why I pushed your described
> change for libgrapheme[0].

There is a big important reason why scc ar does not generates a link table,
because then ar can handle any type of files, because ar is just an archiver.
Making ar(1) to generate symbol tables means that ar has to do detection
of type files, meaning that it has to support all the possible binary formats.

At this moment scc ar is able to generate libraries for any system, without
a symbol table yes, but thay are going to work. In this point we have several
standard to consider. POSIX does not enter in binary formats, it is out of
the scope of the standard, and htis is why as(1) and ld(1) are out of the
specification, and it does not mean that you should not use them, it is just
that they cannot be standarized. ELF specification implies that ar should
generate a symbol table, but not a.out ar. If you want to be sure that you
have a symbl table then you *need* ranlib, otherwise it depends of the system
where you execute.

Again, ranlib(1) is out of POSIX because it cannot standarize this kind of
topics, not because it is legacy. In fact, MacOS requires use of ranlib (or
at least it needed the last time that I tested scc in MacOS). You cannot
know what system require it or not, so the only safe option is to use ranlib.

Regards,



Re: [dev] Replace ranlib(1) calls?

2022-08-01 Thread Roberto E. Vargas Caballero
Hi,

On Sun, Jul 31, 2022 at 12:59:23AM +0200, Laslo Hunhold wrote:
> Granted, it's one thing what a standard defines and another what is
> actually used in everyday life, but calling a standard-defined option
> as _less_ portable than an undefined historical artifact is a stretch.

-std=c99 is not part of any standard and our Makefiles are full of them.
as(1), ld(1), and cc(1) are not part of POSIX and we keep using them.
Again, Please stop doing this kind of patches and center in changes
that actually improve code. If we find a system where using ranli is
a problem then we can revisit this.


Roberto,



Re: [dev] tar filename handling

2022-08-01 Thread Страхиња Радић
On 22/08/01 09:30, Quentin Rameau wrote:
> Andrew has posted a patch (on hackers@ on may first) for this
> that nobody had time to review yet. :/
> I suggest you try it, that should fix your issue.

Ah, I'm not subscribed on that list (yet?). Anyway, I tested my patch on my use 
case and it behaves correctly so far, so I leave you guys to decide whether to 
review/include it or not.

In the meantime, I have posted another patch, which adds a -n option 
(equivalent of --no-recursion) for your consideration.


signature.asc
Description: PGP signature


Re: [dev] tar filename handling

2022-08-01 Thread Quentin Rameau
Hi Страхиња,

> The path that failed was
> 
> ./sucks/lib/python3.9/site-packages/docutils/parsers/__pycache__/commonmark_wrapper.cpython-39.opt-1.pyc
> 
> which is 104 characters long. On further inspection, it seems that the prefix 
> field is taken into account with -x and -t ("small dance..."):

Andrew has posted a patch (on hackers@ on may first) for this
that nobody had time to review yet. :/
I suggest you try it, that should fix your issue.



[dev] tar -n (equivalent of --no-recursion)

2022-08-01 Thread Страхиња Радић
I have made another patch for tar, this is more "quality of life" oriented. It 
adds the option -n to tar, which is equivalent to GNU tar's --no-recursion. 
This comes in handy when tar is used together with find(1) to filter and 
hand-pick the list of files to be archived.

The patch is here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Add-n-equivalent-of-no-recursion.patch

and I have also attached it to this message for review.
From 3c58d0ce54200f001309da369a54cb58a4e7ddf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:21:08 +0200
Subject: [PATCH] Add -n (equivalent of --no-recursion)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.1 |  5 +
 tar.c | 16 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/tar.1 b/tar.1
index be2ebea..f7d27a0 100644
--- a/tar.1
+++ b/tar.1
@@ -15,6 +15,7 @@
 .Op Fl C Ar dir
 .Op Fl J | Fl Z | Fl a | Fl j | Fl z
 .Op Fl h
+.Op Fl n
 .Fl c Ar path ...
 .Op Fl f Ar file
 .Sh DESCRIPTION
@@ -36,6 +37,10 @@ as input | output archive instead of stdin | stdout.
 If '-', stdin | stdout is used.
 .It Fl m
 Do not preserve modification time.
+.It Fl n
+Do not recurse into directories. This flag is an extension to standard,
+equivalent to GNU tar's
+.Fl -no-recursion .
 .It Fl t
 List all files in the archive.
 .It Fl x
diff --git a/tar.c b/tar.c
index d3a9f3b..3f8daf9 100644
--- a/tar.c
+++ b/tar.c
@@ -63,7 +63,7 @@ static int tarfd;
 static ino_t tarinode;
 static dev_t tardev;
 
-static int mflag, vflag;
+static int mflag, nflag, vflag;
 static int filtermode;
 static const char *filtertool;
 
@@ -374,7 +374,7 @@ c(int dirfd, const char *name, struct stat *st, void *data, struct recursor *r)
 	if (vflag)
 		puts(r->path);
 
-	if (S_ISDIR(st->st_mode))
+	if (S_ISDIR(st->st_mode) && !nflag)
 		recurse(dirfd, name, NULL, r);
 }
 
@@ -507,7 +507,7 @@ usage(void)
 {
 	eprintf("usage: %s [-C dir] [-J | -Z | -a | -j | -z] -x [-m | -t] "
 	"[-f file] [file ...]\n"
-	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] -c path ... "
+	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] [-n] -c path ... "
 	"[-f file]\n", argv0, argv0);
 }
 
@@ -534,6 +534,9 @@ main(int argc, char *argv[])
 	case 'm':
 		mflag = 1;
 		break;
+	case 'n':
+		nflag = 1;
+		break;
 	case 'J':
 	case 'Z':
 	case 'a':
@@ -577,7 +580,12 @@ main(int argc, char *argv[])
 		if (chdir(dir) < 0)
 			eprintf("chdir %s:", dir);
 		for (; *argv; argc--, argv++)
-			recurse(AT_FDCWD, *argv, NULL, );
+		{
+			if (!nflag)
+recurse(AT_FDCWD, *argv, NULL, );
+			else
+archive(*argv);
+		}
 		break;
 	case 't':
 	case 'x':
-- 
2.37.1



signature.asc
Description: PGP signature


Re: [dev] tar filename handling

2022-08-01 Thread Страхиња Радић
I have made the necessary change, you can review my patch here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Split-path-into-prefix-name-on-c.patch

I also attached it to this message.
From d91f1b0315ca3a0d584f8ac7c2e8ef16cc7493c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:12:03 +0200
Subject: [PATCH] Split path into prefix + name on -c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tar.c b/tar.c
index d3a9f3b..4c35102 100644
--- a/tar.c
+++ b/tar.c
@@ -180,6 +180,7 @@ static int
 archive(const char *path)
 {
 	char b[BLKSIZ];
+	char *split;
 	struct group *gr;
 	struct header *h;
 	struct passwd *pw;
@@ -187,6 +188,7 @@ archive(const char *path)
 	size_t chksum, i;
 	ssize_t l, r;
 	int fd = -1;
+	int slen, plen;
 
 	if (lstat(path, ) < 0) {
 		weprintf("lstat %s:", path);
@@ -201,7 +203,19 @@ archive(const char *path)
 
 	h = (struct header *)b;
 	memset(b, 0, sizeof(b));
-	estrlcpy(h->name,path,sizeof(h->name));
+	if ((split = strrchr(path, '/')) > path)
+	{
+		plen = strlen(path);
+		slen = (int)(split - path);
+		if (snprintf(h->prefix, sizeof(h->prefix), "%.*s",
+			slen, path) >= sizeof(h->prefix))
+			eprintf("snprintf: input string too long\n");
+		if (snprintf(h->name, sizeof(h->name), "%.*s",
+			(int)(plen-slen-1), path+slen+1) >= sizeof(h->name))
+			eprintf("snprintf: input string too long\n");
+	}
+	else
+		estrlcpy(h->name, path,   sizeof(h->name));
 	putoctal(h->mode,(unsigned)st.st_mode & 0777, sizeof(h->mode));
 	putoctal(h->uid, (unsigned)st.st_uid, sizeof(h->uid));
 	putoctal(h->gid, (unsigned)st.st_gid, sizeof(h->gid));
-- 
2.37.1



signature.asc
Description: PGP signature