From nobody Thu Feb 16 12:58:11 2023 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PHZkH4Ggkz3qPgP for ; Thu, 16 Feb 2023 12:58:15 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 4PHZkG6QpFz3KrC for ; Thu, 16 Feb 2023 12:58:14 +0000 (UTC) (envelope-from freebsd@edvax.de) Authentication-Results: mx1.freebsd.org; none Received: from r56.edvax.de ([178.12.39.114]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPA (Nemesis) id 1Mxlmw-1occHq1j4w-00zIDq; Thu, 16 Feb 2023 13:58:12 +0100 Date: Thu, 16 Feb 2023 13:58:11 +0100 From: Polytropon To: "Steve O'Hara-Smith" Cc: questions@FreeBSD.org, Polytropon Subject: Re: remove double quote character from file names Message-Id: <20230216135811.d4ba5a8c.freebsd@edvax.de> In-Reply-To: <20230216104927.c96efd845f0714a998b7ae9f@sohara.org> References: <1398045780.627028.1676532009651@ichabod.co-bxl> <20230216112431.8252a3d4.freebsd@edvax.de> <20230216104927.c96efd845f0714a998b7ae9f@sohara.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:E5z3ePafl4TGsF76XeexCX8sXD9sUenjjXuImL2yKjlApkoyS4/ h6bcFErO8UYcXI63IpjmmMlUnWSMpL5GrYQGyyIy0tMC3TOOGRQNEogEiijBXB24ZpOsY9y IfqRnB2hSfbC6Ie1wMOgJsSrHebko9mob7QJ5gNaBgzbQp7QqvrltKDqVzxRxhDr/i4hwi5 uR4tc+5bza2Z6LNt3N2Sw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:5xPk9e90v8Y=;7vHe6wT0gcjM3NRPgO8JTSMpRMO weu9ANydKx5vbDiEY10u/LFIEshuTwC68UldwWSlxOXnpChr2TrI06kofMHjwu6H5XnTDD1uu Ysw5xTBCYq2vvMSHCrZauOsOp8K8X9HuIFU8c9bgDW9PmlAOoZ+zADpNovyyXAUNR0VAKZ+7E +iOK2njnBFzzK7Uob1K8uZRz8y14edKWu0Ge4U7ooj7J4Bb2i2RMULX56sTAjXkox3cyyQiK+ lwvzeh1YgqGWgK9e7hKEIqftuZn9fEVZ6jezBDCW+j/VZFpkCpP57vyOjydA/qKFeNx2kqtdt DEDwc3y2n8o8/6WPYNflqjJdrZ4xY5GI8/wCBLyg7AYoh1yuoSwFN2mwnnzvgJ5bL1JbC2mcf jUeKaASP0+1PHqZx6srcfmNdicaXMPEns8crVXlAE4fx4EKWZiLwju1lhNO4VEYyhMf53qNp/ LsZVv1+LZU40J6PjbnpWelSyglu2K5Fiy/0Dgo037gKAKISpoDfKAAkwzkJZzynSSCp+hzLO3 1YAKZOLBE7dq19SGsQeOZ6QZGGFN6Frwr9emrE0ecyQ4x8QCQLjGZOr5G34G/BX5TqcePwWAs 5ZPGBTkN/k0v02E9SCUSVFaNSUFDBERC0qtS3led7Qj8TjVHNrTbn9ZsyDAbIZOfTrzCo2Gp2 IUQ69PuIggbhiyxTThl0rc1FD7nAQ1MKz98wYDyBxg== X-Rspamd-Queue-Id: 4PHZkG6QpFz3KrC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Feb 2023 10:49:27 +0000, Steve O'Hara-Smith wrote: > On Thu, 16 Feb 2023 11:24:31 +0100 > Polytropon wrote: > > > exist in the heap of files to be processed. Selecting a good > > delimiter for input files is hard. Using the "IFS = \n" approach > > works - as long as there are no newlines in filenames (which > > I'm not sure could also be allowed)... ;-) > > Newlines are indeed allowed in filenames viz: > > ✓ steve@steve ~/tmp $ touch 'a > file' > ✓ steve@steve ~/tmp $ echo * > a > file > ✓ steve@steve ~/tmp $ rm 'a > file' > > There are only two byte values not allowed in the 254 bytes of a > filename - NUL and /. AS far as I know, I is "sort of" allowed, because it is subject to interpretation by the filesystem: it indicates a directory entry. NUL is actually part of any filename as its terminator, in terms of common C strings ("blablabla"). So in conclusion, not even setting IFS to newline when iterating over input file lists makes the thing 100 % safe... > The ls command suppresses most of the nastier > possibilities and displays a ? these days hence the use of echo above. In > times past I have constructed confusing directories with the aid of CR and > BS and even the occasional BEL. Yes, BEL is great, but so are the new possibilities of UTF-8. Those byte sequences (which the filesystem doesn't care about as long as it's not '/' or NUL), especially the many lookalikes for ';' (greek question mark), ' ' (lots of spaces), or '-' (lots of dashes, too), bear a huge potential for confusion or fun, depending on what side you are on, user or sysadmin. Files like " " (invisible) or "*.txt" are possible, and I assume there is even a symbol that looks like '/', so maybe a file that looks (!) like "not/a/directory.c" could be created. The times when seeing LOGIN.COM;1 or SYS1.PARMLIB(IEASYS00) or BOB::SYSMGR$DKA300:[HOME.BOB.SRC.MEOW]STUPID.TXT;42 on a UNIX filesystem were a bit of a surprise are long gone. Long live invisible files! :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...