Fix bug in -z handling of trailing NUL in input

The obvious way to fix this would be to adapt lines to split on null.

However, it's actually nontrivial to rewrite lines. In particular it has a
weird implementation to avoid a space leak. See:
https://gitlab.haskell.org/ghc/ghc/-/issues/4334

Also, while that is a small amount of code, it's covered by a rather
complex copyright and I'd have to include that copyright in git-annex.

So, I opted to filter out the trailing empty string instead.

Sponsored-by: Dartmouth College's Datalad project

CHANGELOG

@@ -65,6 +65,7 @@ git-annex (10.20230408) UNRELEASED; urgency=medium
     transition, and suggest using one of the options, or setting
     annex.synccontent.
   * sync: Added -g as a short option for --no-content.
+  * Fix bug in -z handling of trailing NUL in input.
 
  -- Joey Hess <id@joeyh.name>  Sat, 08 Apr 2023 13:57:18 -0400
 

CmdLine/Batch.hs

@@ -115,7 +115,17 @@ batchLines (BatchFormat sep _) = do
   where
 	splitter = case sep of
 		BatchLine -> lines
-		BatchNull -> splitc '\0'
+		BatchNull -> elimemptyend . splitc '\0'
+
+	-- When there is a trailing null on the input, eliminate the empty
+	-- string that splitc generates. Other empty strings elsewhere in
+	-- the list are preserved. This is the same effect as how `lines`
+	-- handles a trailing newline.
+	elimemptyend [] = []
+	elimemptyend (x:[])
+		| null x = []
+		| otherwise = [x]
+	elimemptyend (x:rest) = x : elimemptyend rest
 
 -- When concurrency is enabled at the command line, it is used in batch
 -- mode. But, if it's only set in git config, don't use it, because the

doc/bugs/dropkey_-z_does_not_drop_etc.mdwn

@@ -42,3 +42,4 @@ and also was reported on 10.20230407 to not return anything causing us to stall:
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 
+> [[closing|done]] per my comments --[[Joey]]

doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment

@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-19T17:53:51Z"
+ content="""
+However, after successfully dropping all the keys with `--print0`, there
+is then this oddity:
+
+	git-annex: Batch input parse failure: bad key
+
+That's a bug in nul splitting when there's a trailing nul. Oops. I've
+fixed that.
+
+Also while I reproduced the rest of the behavior, I didn't see this part:
+
+	commitBuffer: resource vanished 
+
+I'm not sure which command that comes from. Probably I think the findkeys,
+if its entire output was not consumed for some reason.
+"""]]