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
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:
htt
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..."):
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
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
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-leg
