Skip to contentSkip to conversation

Revert 70ac1c478 ("src.mk, All pages: Move man* to man/")

DISCUSSION Petr Vorel 5 participants 17 messages Sep 6, 2022 – Apr 26, 2024 Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7

lore
Share & tools
lore

Petr Vorel

author
#0 lore raw

Hi Alejandro,

yesterday you merged this commit (without sending it to ML):
70ac1c478 ("src.mk, All pages: Move man* to man/")

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit. Because saving one extra cd is IMHO more important.

Kind regards,
Petr

#1 lore raw

Hi Petr,

Quoted 5 lines · Petr Vorel

Hi Alejandro,

yesterday you merged this commit (without sending it to ML):
70ac1c478 ("src.mk, All pages: Move man* to man/")

It's good to know that someone realized immediately after my patch. I wanted to know how much it would really hurt others' habits, and a discussion about it would probably have been too artificial. That's why I did it without prior discussion.

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit. Because saving one extra cd is IMHO more important.

I rarely cd. I edit pages from the root of the repo with (in my example, I'll pretend to edit membarrier(2)):

(previous to subsections):
vi m[TAB]2[TAB]memb[TAB]

(after subsections were introduced, but before this change):
vi m[TAB]2/memb[TAB]

(after this patch):
vi m[TAB]m[TAB]2/memb[TAB]

I agree it's two more keystrokes, and it took me so long to decide to change it because two keystrokes all the time are not the most friendly thing in the world, but I think I could live with them.

Do you still think I should revert it?

I guess I'll receive a lot more emails like that in the following days, so I'll wait a little bit more before considering reverting it, but yeah, I may do it; I'm still unsure about what to do.

Kind regards,

Alex

Signature · 2 lines
Alejandro Colomar
<http://www.alejandro-colomar.es/>
#2 lore raw
Quoted 10 lines · Alejandro Colomar

I rarely cd.  I edit pages from the root of the repo with (in my example, I'll pretend to edit membarrier(2)):

(previous to subsections):
vi m[TAB]2[TAB]memb[TAB]

(after subsections were introduced, but before this change):
vi m[TAB]2/memb[TAB]

(after this patch):
vi m[TAB]m[TAB]2/memb[TAB]

Sorry, it's really

vi m[TAB]/m[TAB]2/memb[TAB]

due to the Announce and lsm files. So 3 extra keystrokes.

Quoted 4 lines

I agree it's two more keystrokes, and it took me so long to decide to change it because two keystrokes all the time are not the most friendly thing in the world, but I think I could live with them.

Signature · 2 lines
Alejandro Colomar
<http://www.alejandro-colomar.es/>
#3 lore raw
Quoted 9 lines · Alejandro Colomar
Quoted 8 lines · Alejandro Colomar

I rarely cd.  I edit pages from the root of the repo with (in my example, I'll pretend to edit membarrier(2)):

(previous to subsections):
vi m[TAB]2[TAB]memb[TAB]

(after subsections were introduced, but before this change):
vi m[TAB]2/memb[TAB]

Quoted 8 lines
Quoted 2 lines

(after this patch):
vi m[TAB]m[TAB]2/memb[TAB]

Sorry, it's really

vi m[TAB]/m[TAB]2/memb[TAB]

due to the Announce and lsm files.  So 3 extra keystrokes.

Ahh, no, I can remove a keystroke:

vi m[TAB]/[TAB]2/memb[TAB]

so 2 again.

Quoted 5 lines
Quoted 5 lines

I agree it's two more keystrokes, and it took me so long to decide to change it because two keystrokes all the time are not the most friendly thing in the world, but I think I could live with them.

Signature · 2 lines
Alejandro Colomar
<http://www.alejandro-colomar.es/>
author
#4 lore raw
In reply to Alejandro Colomar

Hi Alejandro,

thanks a lot for your feedback.

Quoted 14 lines

Hi Petr,

Quoted 4 lines · Petr Vorel

Hi Alejandro,

yesterday you merged this commit (without sending it to ML):
70ac1c478 ("src.mk, All pages: Move man* to man/")

It's good to know that someone realized immediately after my patch. I wanted to know how much it would really hurt others' habits, and a discussion about it would probably have been too artificial. That's why I did it without prior discussion.

Quoted 6 lines
Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit. Because saving one extra cd is IMHO more important.

I rarely cd. I edit pages from the root of the repo with (in my example, I'll pretend to edit membarrier(2)):

I also rarely cd. Both cd and editing from the git root directory use using tab autocompletion as you note below.

Quoted 10 lines

(previous to subsections):
vi m[TAB]2[TAB]memb[TAB]

(after subsections were introduced, but before this change):
vi m[TAB]2/memb[TAB]

(after this patch):
vi m[TAB]m[TAB]2/memb[TAB]

Quoted 5 lines

I agree it's two more keystrokes, and it took me so long to decide to change it because two keystrokes all the time are not the most friendly thing in the world, but I think I could live with them.

Do you still think I should revert it?

I'd wait for more feedback, maybe others will like it. Sure, I can live with it if I'm alone who even noticed :).

Quoted 3 lines

I guess I'll receive a lot more emails like that in the following days, so I'll wait a little bit more before considering reverting it, but yeah, I may do it; I'm still unsure about what to do.

No matter how you finally decide, the most important lesson is that tree wide changes, although they look trivial are safer to post to ML to get feedback before (and obviously anything which looks controversial).

Kind regards,
Petr

Quoted 3 lines

Kind regards,

Alex

#5 lore raw
In reply to Petr Vorel

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 1 line

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

I don't like the new layout either.

Signature · 1 line
Jakub Wilk
#6 lore raw

Hi Jakub

Quoted 4 lines · Jakub Wilk

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 1 line

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Cheers,

Alex

Quoted 1 line
Signature · 1 line
<http://www.alejandro-colomar.es/>
#7 lore raw

Hi Alex,

Quoted 9 lines · Alejandro Colomar

Hi Jakub

Quoted 5 lines · Jakub Wilk

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Just my 2 cents,
Stefan.

Quoted 10 lines

Cheers,

Alex

Quoted 1 line

--
<http://www.alejandro-colomar.es/>

author
#8 lore raw
Quoted 20 lines

Hi Alex,

Quoted 8 lines · Alejandro Colomar

Hi Jakub

Quoted 4 lines · Jakub Wilk

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Quoted 7 lines

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Yes, I have experience from other projects that moving around does not help. But here simple revert is working well:

$ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc
git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2
(c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do
it early (don't put new commits before it)
$ git log man2/_exit.2 # shows previous history

Kind regards,
Petr

Quoted 7 lines

Just my 2 cents,
Stefan.

Quoted 3 lines

Cheers,

Alex

#9 lore raw

Hi all,

Quoted 23 lines · Petr Vorel
Quoted 15 lines · Alejandro Colomar
Quoted 6 lines · Jakub Wilk
Quoted 4 lines

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Quoted 7 lines

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Quoted 9 lines

Yes, I have experience from other projects that moving around does not help. But here simple revert is working well:

$ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc
git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2
(c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do
it early (don't put new commits before it)
$ git log man2/_exit.2 # shows previous history

Reverted (before any other patches).

Cheers,

Alex

Signature · 1 line
<http://www.alejandro-colomar.es/>
author
#10 lore raw
Quoted 33 lines

Hi all,

Quoted 29 lines · Petr Vorel
Quoted 15 lines · Alejandro Colomar
Quoted 6 lines · Jakub Wilk
Quoted 4 lines

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Quoted 7 lines

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Yes, I have experience from other projects that moving around does not help. But here simple revert is working well:

$ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc
git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2
(c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do
it early (don't put new commits before it)
Quoted 4 lines
Quoted 1 line
$ git log man2/_exit.2 # shows previous history

Reverted (before any other patches).

Thanks!

Kind regards,
Petr

Quoted 3 lines

Cheers,

Alex

maintainer
#11 lore raw
In reply to Alex Colomar

Hi all,

Quoted 33 lines · Alex Colomar

Hi all,

Quoted 30 lines · Petr Vorel
Quoted 15 lines · Alejandro Colomar
Quoted 6 lines · Jakub Wilk
Quoted 4 lines

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Quoted 7 lines

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Yes, I have experience from other projects that moving around does not help. But here simple revert is working well:

$ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc
git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2
(c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do
it early (don't put new commits before it)
Quoted 4 lines
Quoted 2 lines
$ git log man2/_exit.2 # shows previous history

Reverted (before any other patches).

I'm packaging 6.05 for Debian, and I found issues. The problem is present due a combination of the patch below and not having a man/ dir.

Since we support any kind of dirs within $(MANDIR), and not just man*, make check happily checks any file whose name resembles a manual page. This is useful for linting random projects that put their pages together with their sources, in an unorganized directory structure. Most projects do this.

In the Debian manpages packaging, this finds patches in .pc/, which are placed there by quilt(1).

I see several different solutions to make gbp-buildpackage(1) work:

- My preferred one would be to move (again) the pages to a man/ dir in the root of the project and define MANDIR:=$(srcdir)/man. Then, make check would just ignore .pc/ in the root of the repo.

- Revert the patch below. I don't like it, since then we wouldn't be able to use our build system to lint other project's manual pages, which is an interesting feature.

- Revert the patch in the Debian packaging. However, other distributors may have similar problems.

- Completely disable make check (via override_dh_auto_test) in Debian packaging. I don't like this. I think distros running make check is useful to detect regressions.

What do you think?

Thanks,
Alex

---

commit 11e3443c0c6812460402382857e6af9c83938e47

Author: Alejandro Colomar <[email protected]>
Date:   Sat Apr 29 19:29:50 2023 +0200

*.mk: Allow non-standard source MANDIRS

Some projects don't store their source manual pages in a directory structure resembling $MANPATH. Allow such a directory structure so that we can for example lint groff's source manual pages:

$ make check lint MANDIR=~/src/gnu/groff;

Signed-off-by Alejandro Colomar <[email protected]>
share/mk/build/_.mk +2 -2
index 6cc820073..2f8ae0bcb 100644
@@ -23,12 +23,12 @@ MKDIR := mkdir -p
 RM    := rm
 
 
-NONSO_MAN := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+NONSO_MAN := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -l '^\.TH ' \
                | $(SORT) \
                | $(SED) 's,:,\\:,g')
-NONSO_MDOC := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+NONSO_MDOC := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -l '^\.Dt ' \
                | $(SORT) \
share/mk/build/src.mk +1 -1
index 4da142a74..86d024e2f 100644
@@ -57,7 +57,7 @@ LD  := $(CC) $(CFLAGS)
 _SRCPAGEDIRS   := $(patsubst $(MANDIR)/%,$(_MANDIR)/%.d/,$(NONSO_MAN))
 
 _UNITS_src_src := $(patsubst $(MANDIR)/%,$(_MANDIR)/%,$(shell \
-               $(FIND) $(MANDIR)/man*/ -type f \
+               $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -H '^\.\\" SRC BEGIN ' \
                | $(SED) 's,:\.\\" SRC BEGIN (,.d/,' \
share/mk/src.mk +1 -1
index 76deb8230..169bf7e6d 100644
@@ -15,7 +15,7 @@ MANDIR := $(srcdir)
 MANEXT := \.[0-9]\w*\(\.man\)\?\(\.in\)\?$
 
 
-MANPAGES := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+MANPAGES := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(SORT) \
                | $(SED) 's,:,\\:,g')
Signature · 2 lines
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
maintainer
#12 lore raw
Quoted 51 lines · Alejandro Colomar

Hi all,

Quoted 33 lines · Alex Colomar

Hi all,

Quoted 30 lines · Petr Vorel
Quoted 15 lines · Alejandro Colomar
Quoted 6 lines · Jakub Wilk
Quoted 4 lines

* Petr Vorel <[email protected]>, 2022-09-06 11:41:

Quoted 3 lines

Although I agree that number of man* is quite high and single man directory looks nicer, from practical reasons I'd prefer to revert this commit.

Quoted 7 lines
Quoted 1 line

I don't like the new layout either.

Thank you both for sharing your opinion. I'll revert it, then. Let me a few weeks before doing that, since I'm in the middle of some other big changes (about lint-c), so to not have to stash and fix conflicts at that scale. If in the meantime someone finds the new layout nice, please speak up :)

Quoted 7 lines

I think one other aspect to consider is that it makes history searching harder. If you type 'git log <file>', by default you only get the history to the last move. You need 'git log --follow' to see the whole history. Then if you want to do a 'git blame' on an old version of the file, pre-move, I think you need to find the old path and use that. If the maintainer's opinion of where a file should be changes often, that makes it more fun :).

Yes, I have experience from other projects that moving around does not help. But here simple revert is working well:

$ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc
git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2
(c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do
it early (don't put new commits before it)
Quoted 4 lines
Quoted 2 lines
$ git log man2/_exit.2 # shows previous history

Reverted (before any other patches).

I'm packaging 6.05 for Debian, and I found issues. The problem is present due a combination of the patch below and not having a man/ dir.

Since we support any kind of dirs within $(MANDIR), and not just man*, make check happily checks any file whose name resembles a manual page. This is useful for linting random projects that put their pages together with their sources, in an unorganized directory structure. Most projects do this.

Quoted 8 lines

In the Debian manpages packaging, this finds patches in .pc/, which are placed there by quilt(1).

I see several different solutions to make gbp-buildpackage(1) work:

- My preferred one would be to move (again) the pages to a man/ dir in the root of the project and define MANDIR:=$(srcdir)/man. Then, make check would just ignore .pc/ in the root of the repo.

Hmm, a new one occurs to me: $(FIND) $(MANDIR)/* -type f

That would ignore dot dirs, and would workaround the problem for now.

So, we can forget about this for now. :)

Quoted 80 lines
(quoted diff) +0 -3
-  Revert the patch below.  I don't like it, since then we wouldn't
   be able to use our build system to lint other project's manual
   pages, which is an interesting feature.
 
-  Revert the patch in the Debian packaging.  However, other
   distributors may have similar problems.
 
-  Completely disable `make check` (via override_dh_auto_test) in
   Debian packaging.  I don't like this.  I think distros running
   `make check` is useful to detect regressions.

What do you think?

Thanks,
Alex

---

commit 11e3443c0c6812460402382857e6af9c83938e47

Author: Alejandro Colomar <[email protected]>
Date:   Sat Apr 29 19:29:50 2023 +0200

*.mk: Allow non-standard source MANDIRS

Some projects don't store their source manual pages in a directory structure resembling $MANPATH. Allow such a directory structure so that we can for example lint groff's source manual pages:

$ make check lint MANDIR=~/src/gnu/groff;

Signed-off-by Alejandro Colomar <[email protected]>
share/mk/build/_.mk +2 -2
index 6cc820073..2f8ae0bcb 100644
@@ -23,12 +23,12 @@ MKDIR := mkdir -p
 RM    := rm
 
 
-NONSO_MAN := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+NONSO_MAN := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -l '^\.TH ' \
                | $(SORT) \
                | $(SED) 's,:,\\:,g')
-NONSO_MDOC := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+NONSO_MDOC := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -l '^\.Dt ' \
                | $(SORT) \
share/mk/build/src.mk +1 -1
index 4da142a74..86d024e2f 100644
@@ -57,7 +57,7 @@ LD  := $(CC) $(CFLAGS)
 _SRCPAGEDIRS   := $(patsubst $(MANDIR)/%,$(_MANDIR)/%.d/,$(NONSO_MAN))
 
 _UNITS_src_src := $(patsubst $(MANDIR)/%,$(_MANDIR)/%,$(shell \
-               $(FIND) $(MANDIR)/man*/ -type f \
+               $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(XARGS) $(GREP) -H '^\.\\" SRC BEGIN ' \
                | $(SED) 's,:\.\\" SRC BEGIN (,.d/,' \
share/mk/src.mk +1 -1
index 76deb8230..169bf7e6d 100644
@@ -15,7 +15,7 @@ MANDIR := $(srcdir)
 MANEXT := \.[0-9]\w*\(\.man\)\?\(\.in\)\?$
 
 
-MANPAGES := $(shell $(FIND) $(MANDIR)/man*/ -type f \
+MANPAGES := $(shell $(FIND) $(MANDIR)/ -type f \
                | $(GREP) '$(MANEXT)' \
                | $(SORT) \
                | $(SED) 's,:,\\:,g')
Signature · 2 lines
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
maintainer
#13 lore raw

Move man* to man/ (was: Revert 70ac1c478 ("src.mk, All pages: Move man* to man/"))

In reply to Petr Vorel

Hi,

I'm thinking of adding some features to the build system that would need having a clean man/ directory. The main one is building several books for other projects, one per language, where languages correspond to every directory within man/ that doesn't match man*. Currently, I'm workarounding this by running the build system several times, for each language dir, but it could be much simpler, I think.

For not having a regression in the number of characters one needs to type to edit the manual pages, I thought of adding symlinks in the root of the repository, so it would look like this:

	$ ls -l man*
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man1 -> man/man1/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man2 -> man/man2/
	lrwxrwxrwx  1 alx alx   13 Mar 26 02:25 man2type -> man/man2type/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man3 -> man/man3/
	lrwxrwxrwx  1 alx alx   14 Mar 26 02:26 man3const -> man/man3const/
	lrwxrwxrwx  1 alx alx   13 Mar 26 02:26 man3head -> man/man3head/
	lrwxrwxrwx  1 alx alx   13 Mar 26 02:26 man3type -> man/man3type/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man4 -> man/man4/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man5 -> man/man5/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man6 -> man/man6/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man7 -> man/man7/
	lrwxrwxrwx  1 alx alx    9 Mar 26 02:26 man8 -> man/man8/
	man:
	total 120
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man1
	drwxrwxr-x 2 alx alx 20480 Mar 26 02:24 man2
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man2type
	drwxrwxr-x 2 alx alx 57344 Mar 26 02:24 man3
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man3const
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man3head
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man3type
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man4
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man5
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man6
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man7
	drwxrwxr-x 2 alx alx  4096 Mar 26 02:24 man8

What do you think about it?

Cheers,
Alex

Signature · 2 lines
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
maintainer
#14 lore raw

Ping: Re: Move man* to man/ (was: Revert 70ac1c478 ("src.mk, All pages: Move man* to man/"))

Hi!

Quoted 10 lines · Alejandro Colomar

I'm thinking of adding some features to the build system that would need having a clean man/ directory. The main one is building several books for other projects, one per language, where languages correspond to every directory within man/ that doesn't match man*. Currently, I'm workarounding this by running the build system several times, for each language dir, but it could be much simpler, I think.

For not having a regression in the number of characters one needs to type to edit the manual pages, I thought of adding symlinks in the root of the repository, so it would look like this:

[...]

Quoted 1 line

What do you think about it?

Ping.

To be explicit: I want to

$ mkdir man/
$ mv man* man/
$ ln -st . man/man*

Should I assume that no-one has reasons against this? I'll still take some time before doing the change, to allow replies to this thread. But please manifest youselves, even if just for saying you don't have an opinion. Thanks!

Have a lovely day!
Alex

Quoted 3 lines

Cheers,
Alex

Signature · 1 line
<https://www.alejandro-colomar.es/>
author
#15 lore raw

Re: Ping: Re: Move man* to man/ (was: Revert 70ac1c478 ("src.mk, All pages: Move man* to man/"))

Hi Alex,

Quoted 22 lines

Hi!

Quoted 10 lines · Alejandro Colomar

I'm thinking of adding some features to the build system that would need having a clean man/ directory. The main one is building several books for other projects, one per language, where languages correspond to every directory within man/ that doesn't match man*. Currently, I'm workarounding this by running the build system several times, for each language dir, but it could be much simpler, I think.

For not having a regression in the number of characters one needs to type to edit the manual pages, I thought of adding symlinks in the root of the repository, so it would look like this:

[...]

Quoted 1 line

What do you think about it?

Ping.

To be explicit: I want to

Quoted 8 lines
$ mkdir man/
$ mv man* man/
$ ln -st . man/man*

Should I assume that no-one has reasons against this? I'll still take some time before doing the change, to allow replies to this thread. But please manifest youselves, even if just for saying you don't have an opinion. Thanks!

Obviously have files outside of man/ directory would be better than having to cd to one extra directory. But if you symlink it it should be ok.

But you know the source more than me.

Kind regards,
Petr

Quoted 6 lines

Have a lovely day!
Alex

Quoted 2 lines

Cheers,
Alex

maintainer
#16 lore raw

Re: Ping: Re: Move man* to man/ (was: Revert 70ac1c478 ("src.mk, All pages: Move man* to man/"))

Hi Petr,

Quoted 2 lines · Petr Vorel

Obviously have files outside of man/ directory would be better than having to cd to one extra directory. But if you symlink it it should be ok.

Yep, I don't know how I didn't think of a symlink until recently. :-) I think this should be fine. Anyway, I'll wait a little bit to give the chance to others to speak.

Thanks for your feedback!

Quoted 1 line

But you know the source more than me.

Have a lovely night!
Alex

Signature · 1 line
<https://www.alejandro-colomar.es/>