From owner-freebsd-questions@freebsd.org Tue Sep 22 17:30:26 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C6C623F0D93 for ; Tue, 22 Sep 2020 17:30:26 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwpH54y39z4M2J for ; Tue, 22 Sep 2020 17:30:25 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.5.88]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPA (Nemesis) id 1MFJfN-1kEPOH11gH-00FliT; Tue, 22 Sep 2020 19:30:20 +0200 Date: Tue, 22 Sep 2020 19:30:19 +0200 From: Polytropon To: Kurt Hackenberg Cc: freebsd-questions@freebsd.org Subject: Re: Error message output Message-Id: <20200922193019.9ddd63f7.freebsd@edvax.de> In-Reply-To: <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.com> References: <20200920191108.22864e5c.freebsd@edvax.de> <528b2c90-18c4-9e95-a150-67344154c66c@holgerdanske.com> <20200921132139.286b5bda.freebsd@edvax.de> <8b426d6f-6ebe-d1a7-13af-69cffbcb6222@holgerdanske.com> <20200922005552.4df3c123.freebsd@edvax.de> <0dc8a3a4-85d9-7168-f118-b456aafd3910@holgerdanske.com> <25dc8a18-e276-6f6b-685b-377bdf0ffa73@panix.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:NrxmcFYItayiLl7Fypce/kuZZpThauYphYZdC6gBf1aLKhctwv8 4i7Dua/4WBmQQdCzmTx2jpWkxylqdhga6Kwfi5JEvrJbOjGLi9+BoWe/yOQ6Y4qnwlexbO5 4UVoQLU7MlDGuSvUjRcNx/TlSx68Rb/DJgVAWoyIcEoWHeWMAfrXKqE1I6QgLfS9wIZoS5s 0qc/1deS/RPLrTBZNecDQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Wh0eB4YawJo=:5o1SBPRfZujvLAW4/i9TY3 sL8JNOBdNTH/xvEqSkcujWb6hFZMLsDStjznIuy6m8Ip9ssZA76hX+1N0/RKiRHtEdjMSNhP8 NhyfUuHb3su+f+c4ejyJnW7Onwt1guBGb+UB0RBdRzIOWfBKefLgmRFPApW6xtoZ69AZHMXVx Qih8YVKrTD6A2vBBbkXDMdKeSIZgTamRYWywgitt/ehZDLEz3tvS8p+urjSUJ3JpMHpZ/vQVO eSHjvdU2PbhmSTqCw9b5U2JDRBUTatto4DCye8dc1UdMNTK3PxjLGUtlFokbfcWzbF6AwDwB9 YH58HyDd4AMqy42sg867/2z5ZvQXMXPYyBJH6/MZQdE7hscXxMWMbpxZQKzqCzfV3VjkKH7O3 tzXD0Qny9BJUwyJZgyZO1L5jD8+pBBk+8AIz46Yr7iTKym3RTRBky+JY+Csci+yyyERYNlLQn a8INPyre9R67N/9Y6ysBpkUbkXjCeyOfh9Gv8QkAk2QH7wbGhSm229t4qql/gK6vnUEVj9DC/ UwAB4e2q9PWcXMP7Lqv8UGhbGBFl5N9nk6O/oYtrm/C/bMDLb4iA9e4YXhVeHulHtWpGRTs6T xgDEW/ZkwLgf6QEEaodOV9uVpNxiQtDlI372d5OO2zSGciRgzfBc4rTVERu42i7KMUK4HSUaS F61wurbdZQXWgEXEwSlniG04kDR41DAGEAYJNr3l3Al8+q6evM9ZMTTrhFpf6fi4VKf5ySk/U 88DAD1bQnbxJS9z5A+dkBwJEeUULNzkjgPcROyLTbtlyeWhGZxfnbgTo0yK2iw9aqKwo803/n 0UBX81B4E0lAUuFBm9gSLnTHfaJTzFLDxa8zKb00TlyOiAayFGa3XYVg+q4eJJrkHTBT9Ly X-Rspamd-Queue-Id: 4BwpH54y39z4M2J X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.135) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [0.74 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[94.222.5.88:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.807]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.10)[0.100]; NEURAL_HAM_LONG(-0.95)[-0.949]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.135:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.135:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 17:30:26 -0000 On Tue, 22 Sep 2020 12:53:19 -0400, Kurt Hackenberg wrote: > On 2020-09-22 02:33, David Christensen wrote: >=20 > > Providing a fractional base file name as an argument and computing inpu= t=20 > > and output file names is unconventional.=A0 The FreeBSD convention seem= s=20 > > to be to use complete file names for arguments.=A0 This allows the user= to=20 > > use shell globbing, find(1) and xargs(1), etc., or to wrap this script= =20 > > in another script that computes the arguments. > ... > > When given no options or arguments, the FreeBSD convention seems to be= =20 > > to run the program with a default argument.=A0 If no default makes sens= e,=20 > > then to print the usage message. >=20 >=20 > All true, except these are conventions for all Unixes, not just FreeBSD,= =20 > from sometime early in Unix history. An early example is the program=20 > "cat" (which is easy to write in C). Arguments are input filenames; with= =20 > no arguments it reads stdin. >=20 > The convention that the user supplies file base names, and the program=20 > adds extensions, is strong in some other OSes, including those from=20 > Microsoft and Digital Equipment Corporation. This is tied to the idea,=20 > more or less built into those systems, that the file extension is=20 > separate and special, and has meaning. In fact, in those filesystems,=20 > the file extension is stored separately from the base name, and the '.'=20 > is not stored at all. (Well, I don't know that about NTFS.) >=20 > In Unix, the opposite convention is equally strong: a filename is just a= =20 > single string, and is not parsed; the user supplies complete filenames.=20 > In a Unix filename, '.' is stored as part of the name, and has no=20 > special meaning. A filename can include zero or more suffixes that start= =20 > with '.'. Executable programs usually have zero; "foo.tar.gz" has two. >=20 > Yes, there are mild exceptions -- compilers, make, ls (by default=20 > ignores names that start with '.') -- but this is the origin. Exactly. That's why I should add further development time to the little script; not just that it makes assumptions about file names which _may_ be true, but don't always apply ("base_nnn.png" needs to be resolved where nnn, the counter, is replaced by * and then evaluated by the scripting shell). More flexibility is always better, be it different base names, names not following the format expected, or input file lists generated by a different tool or step. In UNIX, a file can have generally any name, the extension(s) have a meaning usually only to the user; "blah" could be a PDF file, and "xpdf blah" would work, and a C compiler would happily compile a source file named "perry_the_platypus". The interpretation of special cases, such as leading "." by ls, is program-specific. The filesystem adds special interpretation for entries "." and "..", as well as for the character "/", but anything else, non-printable characters, tabs and spaces, special characters, even linebreaks could probably make a truly valid (!) filename. Not all valid filenames are useful, though... ;-) In systems where all parts interpret filenames as a concept of "base.extension", and decide for actions according to extension, the flexibility of UNIX filenames can cause confusion. If you accidentally remove the ".pdf" from a PDF filename, the file can no longer easily be opened (except maybe by "Open with...") until the ".pdf" is added back again; adding ".mp3" instead causes much more confusion for the system and the user. Imagine what stops working if you add a VMS-like ";version". :-) --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...