rm behaves different in TW and Leap
Hi, I have the following line in a spec file: #...and delete dot files rm %{buildroot}/usr/src/%{name}/.* In TW it works as expected: [ 102s] + rm /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.clang-format /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hg_archival.txt /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgignore /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgtags /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.travis.yml [ 102s] + xargs /bin/rm -f In Leap it fails: [ 24s] + rm /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/. /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.. /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.clang-format /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hg_archival.txt /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgignore /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgtags /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.travis.yml [ 24s] rm: cannot remove '/home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.': Is a directory [ 24s] rm: cannot remove '/home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/..': Is a directory [ 24s] error: Bad exit status from /var/tmp/rpm-tmp.fMLU37 (%install) Any good idea to work around this? NB, in the files section it fails to fid the ot files, thats why I delete them Thanks Axel
Hello Axel, * On Sat, Dec 21, 2024 at 01:03:02PM +0100 Axel Braun wrote:
#...and delete dot files rm %{buildroot}/usr/src/%{name}/.*
This is not a difference in the rm command, but in file expansion. Have a look at the resulting command lines:
In TW it works as expected: [ 102s] + rm /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.clang-format /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hg_archival.txt /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgignore /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgtags /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.travis.yml [...]
In Leap it fails: [ 24s] + rm /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/. /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.. /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.clang-format /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hg_archival.txt /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgignore /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.hgtags /home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.travis.yml [ 24s] rm: cannot remove '/home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/.': Is a directory [ 24s] rm: cannot remove '/home/abuild/rpmbuild/BUILDROOT/orthanc-1.12.5-0.x86_64/usr/src/orthanc/..': Is a directory
Note that here, it also expands . and .. as matching the .* (which, technically, is correct). That's where you error message comes from. I do not know which program expands the .* in your cases; I expect there to be a difference in program or in version. You can work around it by using another command, for example find: find %{buildroot}/usr/src/%{name}/.* -maxdepth 1 -type f -name .\* -exec rm \{\} \+ Note the -maxdepth 1 which makes sure it does not advance into sub-dirs, and the -type f which makes sure that only files are processed. Viele Grüße Spiro -- Spiro R. Trikaliotis https://spiro.trikaliotis.net/
rm %{buildroot}/usr/src/%{name}/.[!.]* -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
On Dez 21 2024, Jan Engelhardt wrote:
On Saturday 2024-12-21 14:54, Andreas Schwab wrote:
rm %{buildroot}/usr/src/%{name}/.[!.]*
That's not POSIX sh compatible
In which way? -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
On Saturday 2024-12-21 15:55, Andreas Schwab wrote:
On Dez 21 2024, Jan Engelhardt wrote:
On Saturday 2024-12-21 14:54, Andreas Schwab wrote:
rm %{buildroot}/usr/src/%{name}/.[!.]*
That's not POSIX sh compatible
In which way?
Nevermind - I ran into a situation where it did not expand, and incorrectly concluded it would not expand at any time.
I just use "rm .../.??*" On Sat, Dec 21, 2024 at 9:23 AM Jan Engelhardt <ej@inai.de> wrote:
On Saturday 2024-12-21 15:55, Andreas Schwab wrote:
On Dez 21 2024, Jan Engelhardt wrote:
On Saturday 2024-12-21 14:54, Andreas Schwab wrote:
rm %{buildroot}/usr/src/%{name}/.[!.]*
That's not POSIX sh compatible
In which way?
Nevermind - I ran into a situation where it did not expand, and incorrectly concluded it would not expand at any time.
In any case, it's a new feature of bash 5.2: aa. The new `globskipdots' shell option forces pathname expansion never to return `.' or `..' unless explicitly matched. It is enabled by default. A future revision of POSIX will probably require this behaviour. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Am Samstag, 21. Dezember 2024, 21:10:20 Mitteleuropäische Normalzeit schrieb Andreas Schwab:
In any case, it's a new feature of bash 5.2:
aa. The new `globskipdots' shell option forces pathname expansion never to return `.' or `..' unless explicitly matched. It is enabled by default.
Ah, thats probably why Leap and TW behave different Thanks to all for your help! Axel
On Sat, Dec 21, 2024 at 9:31 AM Manfred Hollstein <mhollstein@t-online.de> wrote:
On Sat, 21 Dec 2024, 18:25:41 +0100, Lee Duncan wrote:
I just use "rm .../.??*"
Yeah, that's what I normally use, too, but it won't cover files like
.a .b .c ...
You get it ;-)
Cheers.
l8er manfred
Nobody creates files with names like those.But maybe this project is unique?
participants (7)
-
Andreas Schwab -
Axel Braun -
Jan Engelhardt -
Lee Duncan -
Manfred Hollstein -
Sara Blackburn -
Spiro Trikaliotis