Re: "complete -o filenames" sometimes not working

[Grisha Levit]

On Sat, Nov 9, 2024, 07:41 Clark Wang  wrote:

> On Sat, Nov 9, 2024 at 1:48 AM Chet Ramey  wrote:
>
> >
> > OK. You asked for the completions to be treated as filenames. When
> > readline displays the possible completions for filenames, it doesn't
> > display the full pathname -- just the portion after the final slash.
> > The words with ProxyCommand= are trimmed to the portion after the
> > .../usr/bin/.
> >
>
> Ah I didn't realize it's only the basename part being displayed. Any way to
> have it display the full pathnames?


If your goal is to have readline do the quoting for you, without treating
the completions as filenames, the next version of bash (5.3, see the
'devel' branch in the git repo) will have the '-o fullquote' option for
compgen/compopt.

>

Re: [PATCH] lib/readline/doc makefiles clean targets

[Chet Ramey]

On 11/8/24 4:15 PM, Mike Jonkmans wrote:


I could use a GNUMakefile to get around some of the issues.
A fix would be nice.


It wasn't a difficult fix.




2) The use of recursive make, makes it harder to do dependencies right;

It's the best way to build using optional components and subdirectories.


I have my doubts here. There are potential problems with dependencies
and parallel makes wrt linking.


Well, sure. There are always potential problems. But we have to have a
real build problem on a real system that's due to parallel make and
dependencies, so we know whether or not we've fixed anything.



3) The various Makefiles disagree on 'clean: mostlyclean' versus
 'mostlyclean: clean';

Is this substantive or just cosmetic?


It's a minor cognitive burden, mostly cosmetic.


I can swap those around as I modify the individual makefiles; it's not a
big deal.




4) .PHONY is not used for the sub-makes *clean rules;

You mean in the subdirectory makefiles?

Yes. Though I was focussing on the clean rules.
Only two Makefiles have (incomplete) .PHONY rules:
# find . -name Makefile | xargs grep PHONY
./lib/malloc/Makefile:.PHONY:   malloc stubmalloc
./Makefile:.PHONY: basic-clean clean maintainer-clean distclean 
mostlyclean maybe-clean

One can argue about the substantive versus cosmetic aspect of .PHONY.
As it is highly unlikely to accidently create a file named after a target.
But they don't hurt - and FWIW may save a stat or two.


Sure, I can add those as well.




5) git (status), .gitignore and make are disconnected;

What does this mean? There are a couple of files that I need to add
to .gitignore; is this something else?


I suggest per directory .gitignore files, that contain:


This isn't really a problem description.



6) There is redundancy/duplication in the actions of various rules;

OK.

6) Same for the definitions of variables.

Examples?


There is duplication in the top Makefile on the various lib sources.
One might dedup that by creating e.g. lib/glob/Makefile.ext and include
that on the toplevel (the lib's Makefile should then use GLOB_SOURCES).


I don't really consider that a problem.



lib/glob/Makefile:
Seems that gmisc.c is missing from CSOURCES
CSOURCES might then be derived from OBJECTS.


The source files don't change often enough to make that work worth it.



The top Makefile defines GLOB_SOURCES, different from those CSOURCES.
Oh, i see, #include "glob_loop.c" etc. :(


This is a fairly common idiom for building single-byte and multibyte
versions of functions from the same source without duplicating too much
code. glibc and gnulib both use it.


Those *_loop.c files are not included in CSOURCES nor in HSOURCES.


OK.


Could be a problem for the what-tar target (via THINGS_TO_TAR).


Those targets aren't used; I inherited them from the original glob
library. Bash distributions are built a different way.


(One could argue, whether the devel branch is a distribution.)

It's not. It's a snapshot of ongoing work.

As such, it has the purpose of:
- bringing in early fixes/patches;
- communicating future changes, eliciting comments.

In many cases, yes. In some cases, I solicit discussion, usually here.

So the devel branch should be easy to work with for outsiders.

How would the standard make targets make it easier to work with (besides
fixing a couple of previously-discussed issues)? What are we doing here
beyond `configure; make' and testing out various behaviors?


Making people not chase red herrings. I mean that in the output of
'make mostlylean', seeing 'clean' called, makes me want
to look at what is wrong.


You're assuming something is wrong based on a set of assumptions about
how things `should be', not whether anything is actually misbehaving.


(From 'info (make)Standard Targets')
All GNU programs should have the following targets in their Makefiles:
all install install-html install-dvi install-pdf install-ps
install-strip uninstall
clean distclean mostlyclean maintainer-clean
TAGS info dvi html pdf ps dist check installcheck installdirs

The wording has 'should have'. But I think that if you have any of these
targets, they should be doing the expected.


What is `the expected'? The only one we're really missing here is
`installcheck', and few programs seem to have or use it (bash doesn't
install anything but the man pages and info files).


Indeed, building ouside of the source directories will not encounter
the .gitignore problems.
Vaguely rembering some problems with building outside the source.
I shall give that another try.


I rarely build in the source tree.


- 'make mostlyclean' removes doc/bashref.* and doc/Makefile.

It shouldn't remove the Makefile, and you can make it again, but I can't
reproduce it removing the bashref.* files.


On devel:
make distclean
git restore .
./configure
make mostlyclean
git status
Shows several lines o

Re: "complete -o filenames" sometimes not working

[Chet Ramey]

On 11/9/24 7:38 AM, Clark Wang wrote:
On Sat, Nov 9, 2024 at 1:48 AM Chet Ramey > wrote:



OK. You asked for the completions to be treated as filenames. When
readline displays the possible completions for filenames, it doesn't
display the full pathname -- just the portion after the final slash.
The words with ProxyCommand= are trimmed to the portion after the
.../usr/bin/.


Ah I didn't realize it's only the basename part being displayed. Any way to 
have it display the full pathnames?


There is not, no.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature