Thank you for the feedback. I agree that there is overlap with existing utilities. It is true that we can achieve most of the functionality but those tools like install, which is primarily an install/copyutility, its normal usecase is “copy or install this source to this destination, applying attributes.” Using /dev/null as the source works, but it is still an install/copy-shaped operation.
Similarly, touch can create a missing file, but its documented purpose is timestamp manipulation. The creation behavior is useful, but touch is not primarily an attributed file-initialization interface. There are also tools like fallocate, truncate, dd. They have their own purpose, although some functionally overlaps with crtfile. The main motivation for crtfile is not that each individual operation is impossible today. Rather, it is that there is no dedicated user-facing utility for creating a new file with requested initialization properties. Today this often requires composing several tools whose main purposes are different. So the intended value/usecase is a clearer file-creation interface, not only a new way to set mode. It makes the create-new-and-initialize operation explicit instead of expressing it indirectly through several existing commands. That said, I understand the concern that this may still be overlapping for coreutils. I mainly wanted to clarify the intended use case. Also, thank you also for the naming point. I agree that crtfile can look certificate-related, so maybe mkfile (similar to mktemp or mkdir) for a file-handling utility. Regards, Arka On Fri, May 29, 2026 at 3:38 PM Sam James <[email protected]> wrote: > > Collin Funk <[email protected]> writes: > > > Not related to functionality, but from reading the subject I thought > > 'crtfile' was something to interact with certificates. Maybe that is > > just me, though. > > No, I thought the same. > > > > > Collin > > sam
