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. Regards, Arka On Fri, May 29, 2026 at 2:42 AM Pádraig Brady <[email protected]> wrote: > > On 28/05/2026 08:20, Arka Mondal wrote: > > Hello, > > > > I would like to discuss whether crtfile could be considered as a possible > > new command for GNU coreutils. > > > > I originally submitted crtfile for GNU package evaluation as a separate GNU > > package. After reviewing the tarball, it was suggested that the utility fit > > better as a new command in coreutils rather than as a separate GNU > > package. I was advised to discuss on this mailing list before proceeding > > further. > > > > crtfile creates new files with specified attributes, such as permission > > mode, owner, size, and optional initial content. The motivation is to > > create a dedicated file handling utility. > > > > Although there are changes that need to be made such as updating the bug > > reporting address before a final v1.0.0 release. But overall the tarball > > contains the utility to be released as v1.0.0 (source code-wise) > > > > The tarball is available here: crtfile > > <https://drive.google.com/file/d/1NM4a70-c-fiqaNjQkyXqKq3KkZkDFSJr/view?usp=sharing> > > > > If Google Drive is not convenient, I can provide the tarball in another > > preferred way. > > > > I would appreciate feedback on it, and what the preferred next step is. > > > > Thank you for your time. > > > > Yours sincerely, > > Arka > > There are indeed overlaps with lots of existing coreutils. > Also relevant is the suggested touch --mode option, > with pertinent points mention in the associated thread: > https://lists.gnu.org/archive/html/coreutils/2011-01/msg00025.html > Also there is overlap with the fallocate utility. > > I'm not convinced about the need to add to coreutils though. > What is the main use case over combining existing utilities? > One I can think of is setting the mode atomically, > though with umask we can control all but the execute bit atomically, > and it's unusual to be creating files with executable bit set. > > cheers, > Padraig
