2015-05-06 17:44:53 +00:00
|
|
|
{- git-annex batch commands
|
|
|
|
-
|
2021-08-25 18:20:33 +00:00
|
|
|
- Copyright 2015-2021 Joey Hess <id@joeyh.name>
|
2015-05-06 17:44:53 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2015-05-06 17:44:53 +00:00
|
|
|
-}
|
|
|
|
|
|
|
|
module CmdLine.Batch where
|
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
import qualified Annex
|
2016-01-20 20:36:33 +00:00
|
|
|
import Types.Command
|
|
|
|
import CmdLine.Action
|
|
|
|
import CmdLine.GitAnnex.Options
|
2020-07-22 18:23:28 +00:00
|
|
|
import CmdLine.Seek
|
2016-01-20 20:36:33 +00:00
|
|
|
import Options.Applicative
|
make --batch honor matching options
When --batch is used with matching options like --in, --metadata, etc, only
operate on the provided files when they match those options. Otherwise, a
blank line is output in the batch protocol.
Affected commands: find, add, whereis, drop, copy, move, get
In the case of find, the documentation for --batch already said it honored
the matching options. The docs for the rest didn't, but it makes sense to
have them honor them. While this is a behavior change, why specify the
matching options with --batch if you didn't want them to apply?
Note that the batch output for all of the affected commands could
already output a blank line in other cases, so batch users should
already be prepared to deal with it.
git-annex metadata didn't seem worth making support the matching options,
since all it does is output metadata or set metadata, the use cases for
using it in combination with the martching options seem small. Made it
refuse to run when they're combined, leaving open the possibility for later
support if a use case develops.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
|
|
|
import Limit
|
|
|
|
import Types.FileMatcher
|
2020-04-09 17:54:43 +00:00
|
|
|
import Annex.BranchState
|
2020-07-22 18:23:28 +00:00
|
|
|
import Annex.WorkTree
|
|
|
|
import Annex.Content
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
import Annex.Concurrent
|
|
|
|
import Types.Concurrency
|
2015-05-06 17:44:53 +00:00
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
data BatchMode = Batch BatchFormat | NoBatch
|
|
|
|
|
2021-08-25 18:20:33 +00:00
|
|
|
data BatchFormat = BatchFormat BatchSeparator BatchKeys
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2021-08-25 18:20:33 +00:00
|
|
|
data BatchSeparator = BatchLine | BatchNull
|
|
|
|
|
|
|
|
newtype BatchKeys = BatchKeys Bool
|
|
|
|
|
|
|
|
parseBatchOption :: Bool -> Parser BatchMode
|
|
|
|
parseBatchOption supportbatchkeysoption = go
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
<$> switch
|
|
|
|
( long "batch"
|
2021-08-25 18:20:33 +00:00
|
|
|
<> help batchhelp
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
)
|
2021-08-25 18:20:33 +00:00
|
|
|
<*> batchkeysswitch
|
|
|
|
<*> flag BatchLine BatchNull
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
( short 'z'
|
|
|
|
<> help "null delimited batch input"
|
|
|
|
)
|
|
|
|
where
|
2021-08-25 18:20:33 +00:00
|
|
|
go True False batchseparator =
|
|
|
|
Batch (BatchFormat batchseparator (BatchKeys False))
|
|
|
|
go _ True batchseparator =
|
|
|
|
Batch (BatchFormat batchseparator (BatchKeys True))
|
|
|
|
go _ _ _ = NoBatch
|
|
|
|
|
|
|
|
batchhelp = "enable batch mode" ++
|
|
|
|
if supportbatchkeysoption
|
|
|
|
then ", with files input"
|
|
|
|
else ""
|
|
|
|
batchkeyshelp = "enable batch mode, with keys input"
|
|
|
|
|
|
|
|
batchkeysswitch
|
|
|
|
| supportbatchkeysoption = switch
|
|
|
|
( long "batch-keys"
|
|
|
|
<> help batchkeyshelp
|
|
|
|
)
|
|
|
|
| otherwise = pure False
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2015-12-21 16:57:13 +00:00
|
|
|
-- A batchable command can run in batch mode, or not.
|
2015-05-06 17:44:53 +00:00
|
|
|
-- In batch mode, one line at a time is read, parsed, and a reply output to
|
|
|
|
-- stdout. In non batch mode, the command's parameters are parsed and
|
|
|
|
-- a reply output for each.
|
2020-09-16 14:18:36 +00:00
|
|
|
--
|
|
|
|
-- Note that the actions are not run concurrently.
|
2020-09-14 20:49:33 +00:00
|
|
|
batchable :: (opts -> SeekInput -> String -> Annex Bool) -> Parser opts -> CmdParamsDesc -> CommandParser
|
2015-07-12 00:43:45 +00:00
|
|
|
batchable handler parser paramdesc = batchseeker <$> batchparser
|
2015-05-06 17:44:53 +00:00
|
|
|
where
|
2015-07-12 00:43:45 +00:00
|
|
|
batchparser = (,,)
|
|
|
|
<$> parser
|
2021-08-25 18:20:33 +00:00
|
|
|
<*> parseBatchOption False
|
2015-07-12 00:43:45 +00:00
|
|
|
<*> cmdParams paramdesc
|
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchseeker (opts, NoBatch, params) =
|
2020-09-14 20:49:33 +00:00
|
|
|
mapM_ (\p -> go NoBatch opts (SeekInput [p], p)) params
|
2022-01-26 16:59:55 +00:00
|
|
|
batchseeker (opts, batchmode@(Batch fmt), params) =
|
|
|
|
batchOnly Nothing params $
|
|
|
|
batchInput fmt (pure . Right) (go batchmode opts)
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2020-09-14 20:49:33 +00:00
|
|
|
go batchmode opts (si, p) =
|
|
|
|
unlessM (handler opts si p) $
|
2015-07-12 00:43:45 +00:00
|
|
|
batchBadInput batchmode
|
2015-05-06 17:44:53 +00:00
|
|
|
|
|
|
|
-- bad input is indicated by an empty line in batch mode. In non batch
|
|
|
|
-- mode, exit on bad input.
|
|
|
|
batchBadInput :: BatchMode -> Annex ()
|
|
|
|
batchBadInput NoBatch = liftIO exitFailure
|
2021-08-25 18:20:33 +00:00
|
|
|
batchBadInput _ = liftIO $ putStrLn ""
|
2015-12-21 16:57:13 +00:00
|
|
|
|
2020-04-15 20:04:05 +00:00
|
|
|
-- Reads lines of batch mode input, runs a parser, and passes the result
|
|
|
|
-- to the action.
|
|
|
|
--
|
|
|
|
-- Note that if the batch input includes a worktree filename, it should
|
|
|
|
-- be converted to relative. Normally, filename parameters are passed
|
|
|
|
-- through git ls-files, which makes them relative, but batch mode does
|
|
|
|
-- not use that, and absolute worktree files are likely to cause breakage.
|
2020-09-14 20:49:33 +00:00
|
|
|
batchInput :: BatchFormat -> (String -> Annex (Either String v)) -> ((SeekInput, v) -> Annex ()) -> Annex ()
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchInput fmt parser a = go =<< batchLines fmt
|
2015-12-22 16:20:39 +00:00
|
|
|
where
|
2016-12-13 19:35:04 +00:00
|
|
|
go [] = return ()
|
|
|
|
go (l:rest) = do
|
2020-09-14 20:49:33 +00:00
|
|
|
either parseerr (\v -> a (SeekInput [l], v)) =<< parser l
|
2016-12-13 19:35:04 +00:00
|
|
|
go rest
|
2016-11-16 01:29:54 +00:00
|
|
|
parseerr s = giveup $ "Batch input parse failure: " ++ s
|
2016-01-19 21:46:46 +00:00
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchLines :: BatchFormat -> Annex [String]
|
2021-08-25 18:20:33 +00:00
|
|
|
batchLines (BatchFormat sep _) = do
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
checkBatchConcurrency
|
2020-07-06 16:09:53 +00:00
|
|
|
enableInteractiveBranchAccess
|
2020-04-09 17:54:43 +00:00
|
|
|
liftIO $ splitter <$> getContents
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
where
|
2021-08-25 18:20:33 +00:00
|
|
|
splitter = case sep of
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
BatchLine -> lines
|
2023-05-19 18:34:02 +00:00
|
|
|
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
|
2016-12-13 19:35:04 +00:00
|
|
|
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
-- 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
|
|
|
|
-- program using batch mode may not expect interleaved output.
|
|
|
|
checkBatchConcurrency :: Annex ()
|
|
|
|
checkBatchConcurrency = Annex.getState Annex.concurrency >>= \case
|
|
|
|
ConcurrencyCmdLine _ -> noop
|
|
|
|
ConcurrencyGitConfig _ ->
|
|
|
|
setConcurrency (ConcurrencyGitConfig (Concurrent 1))
|
|
|
|
|
2020-09-16 14:53:16 +00:00
|
|
|
batchCommandAction :: CommandStart -> Annex ()
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
batchCommandAction = commandAction . batchCommandStart
|
2020-09-16 14:53:16 +00:00
|
|
|
|
2016-01-19 21:46:46 +00:00
|
|
|
-- The batch mode user expects to read a line of output, and it's up to the
|
|
|
|
-- CommandStart to generate that output as it succeeds or fails to do its
|
|
|
|
-- job. However, if it stops without doing anything, it won't generate
|
2020-09-16 14:53:16 +00:00
|
|
|
-- any output. This modifies it so in that case, an empty line is printed.
|
|
|
|
batchCommandStart :: CommandStart -> CommandStart
|
|
|
|
batchCommandStart a = a >>= \case
|
|
|
|
Just v -> return (Just v)
|
|
|
|
Nothing -> do
|
2021-08-25 18:20:33 +00:00
|
|
|
batchBadInput (Batch (BatchFormat BatchLine (BatchKeys False)))
|
2020-09-16 14:53:16 +00:00
|
|
|
return Nothing
|
2016-01-20 16:46:00 +00:00
|
|
|
|
|
|
|
-- Reads lines of batch input and passes the filepaths to a CommandStart
|
|
|
|
-- to handle them.
|
make --batch honor matching options
When --batch is used with matching options like --in, --metadata, etc, only
operate on the provided files when they match those options. Otherwise, a
blank line is output in the batch protocol.
Affected commands: find, add, whereis, drop, copy, move, get
In the case of find, the documentation for --batch already said it honored
the matching options. The docs for the rest didn't, but it makes sense to
have them honor them. While this is a behavior change, why specify the
matching options with --batch if you didn't want them to apply?
Note that the batch output for all of the affected commands could
already output a blank line in other cases, so batch users should
already be prepared to deal with it.
git-annex metadata didn't seem worth making support the matching options,
since all it does is output metadata or set metadata, the use cases for
using it in combination with the martching options seem small. Made it
refuse to run when they're combined, leaving open the possibility for later
support if a use case develops.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
|
|
|
--
|
2020-09-16 14:18:36 +00:00
|
|
|
-- File matching options are checked, and non-matching files skipped.
|
2021-08-25 18:20:33 +00:00
|
|
|
batchFiles :: BatchFormat -> ((SeekInput, RawFilePath) -> CommandStart) -> Annex ()
|
|
|
|
batchFiles fmt a = batchFilesKeys fmt $ \(si, v) -> case v of
|
|
|
|
Right f -> a (si, f)
|
|
|
|
Left _k -> return Nothing
|
|
|
|
|
|
|
|
batchFilesKeys :: BatchFormat -> ((SeekInput, Either Key RawFilePath) -> CommandStart) -> Annex ()
|
|
|
|
batchFilesKeys fmt a = do
|
make --batch honor matching options
When --batch is used with matching options like --in, --metadata, etc, only
operate on the provided files when they match those options. Otherwise, a
blank line is output in the batch protocol.
Affected commands: find, add, whereis, drop, copy, move, get
In the case of find, the documentation for --batch already said it honored
the matching options. The docs for the rest didn't, but it makes sense to
have them honor them. While this is a behavior change, why specify the
matching options with --batch if you didn't want them to apply?
Note that the batch output for all of the affected commands could
already output a blank line in other cases, so batch users should
already be prepared to deal with it.
git-annex metadata didn't seem worth making support the matching options,
since all it does is output metadata or set metadata, the use cases for
using it in combination with the martching options seem small. Made it
refuse to run when they're combined, leaving open the possibility for later
support if a use case develops.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
|
|
|
matcher <- getMatcher
|
2021-08-25 18:20:33 +00:00
|
|
|
go $ \si v -> case v of
|
|
|
|
Right f ->
|
2023-10-26 17:41:17 +00:00
|
|
|
ifM (matcher $ MatchingFile $ FileInfo f f Nothing)
|
|
|
|
( a (si, Right f)
|
2021-08-25 18:20:33 +00:00
|
|
|
, return Nothing
|
|
|
|
)
|
|
|
|
Left k -> a (si, Left k)
|
2020-09-16 14:18:36 +00:00
|
|
|
where
|
2021-08-25 18:20:33 +00:00
|
|
|
go a' = batchInput fmt parser (batchCommandAction . uncurry a')
|
|
|
|
parser = case fmt of
|
|
|
|
-- Absolute filepaths are converted to relative,
|
|
|
|
-- because in non-batch mode, that is done when
|
|
|
|
-- CmdLine.Seek uses git ls-files.
|
|
|
|
BatchFormat _ (BatchKeys False) ->
|
2023-10-26 17:41:17 +00:00
|
|
|
Right . Right
|
2021-08-25 18:20:33 +00:00
|
|
|
<$$> liftIO . relPathCwdToFile . toRawFilePath
|
|
|
|
BatchFormat _ (BatchKeys True) -> \i ->
|
|
|
|
pure $ case deserializeKey i of
|
|
|
|
Just k -> Right (Left k)
|
|
|
|
Nothing -> Left "not a valid key"
|
|
|
|
|
|
|
|
batchAnnexedFiles :: BatchFormat -> AnnexedFileSeeker -> Annex ()
|
|
|
|
batchAnnexedFiles fmt seeker = batchAnnexed fmt seeker (const (return Nothing))
|
|
|
|
|
|
|
|
-- Reads lines of batch input and passes filepaths to the AnnexedFileSeeker
|
|
|
|
-- to handle them. Or, with --batch-keys, passes keys to the keyaction.
|
|
|
|
--
|
|
|
|
-- Matching options are checked, and non-matching items skipped.
|
|
|
|
batchAnnexed :: BatchFormat -> AnnexedFileSeeker -> ((SeekInput, Key, ActionItem) -> CommandStart) -> Annex ()
|
|
|
|
batchAnnexed fmt seeker keyaction = do
|
|
|
|
matcher <- getMatcher
|
|
|
|
batchFilesKeys fmt $ \(si, v) ->
|
|
|
|
case v of
|
use lookupKeyStaged in --batch code paths
Make --batch mode handle unstaged annexed files consistently whether the
file is unlocked or not. Before this, a unstaged locked file
would have the symlink on disk examined and operated on in --batch mode,
while an unstaged unlocked file would be skipped.
Note that, when not in batch mode, unstaged files are skipped over too.
That is actually somewhat new behavior; as late as 7.20191114 a
command like `git-annex whereis .` would operate on unstaged locked
files and skip over unstaged unlocked files. That changed during
optimisation of CmdLine.Seek with apparently little fanfare or notice.
Turns out that rmurl still behaved that way when given an unstaged file
on the command line. It was changed to use lookupKeyStaged to
handle its --batch mode. That also affected its non-batch mode, but
since that's just catching up to the change earlier made to most
other commands, I have not mentioed that in the changelog.
It may be that other uses of lookupKey should also change to
lookupKeyStaged. But it may also be that would slow down some things,
or lead to unwanted behavior changes, so I've kept the changes minimal
for now.
An example of a place where the use of lookupKey is better than
lookupKeyStaged is in Command.AddUrl, where it looks to see if the file
already exists, and adds the url to the file when so. It does not matter
there whether the file is staged or not (when it's locked). The use of
lookupKey in Command.Unused likewise seems good (and faster).
Sponsored-by: Nicholas Golder-Manning on Patreon
2022-10-26 18:23:06 +00:00
|
|
|
Right f -> lookupKeyStaged f >>= \case
|
2022-10-26 17:58:20 +00:00
|
|
|
Nothing -> return Nothing
|
|
|
|
Just k -> checkpresent k $
|
2021-08-25 18:20:33 +00:00
|
|
|
startAction seeker si f k
|
|
|
|
Left k -> ifM (matcher (MatchingInfo (mkinfo k)))
|
|
|
|
( checkpresent k $
|
|
|
|
keyaction (si, k, mkActionItem k)
|
|
|
|
, return Nothing)
|
|
|
|
where
|
|
|
|
checkpresent k cont = case checkContentPresent seeker of
|
|
|
|
Just v -> do
|
|
|
|
present <- inAnnex k
|
|
|
|
if present == v
|
|
|
|
then cont
|
|
|
|
else return Nothing
|
|
|
|
Nothing -> cont
|
|
|
|
|
|
|
|
mkinfo k = ProvidedInfo
|
|
|
|
{ providedFilePath = Nothing
|
|
|
|
, providedKey = Just k
|
|
|
|
, providedFileSize = Nothing
|
|
|
|
, providedMimeType = Nothing
|
|
|
|
, providedMimeEncoding = Nothing
|
|
|
|
, providedLinkType = Nothing
|
|
|
|
}
|
2022-01-26 16:59:55 +00:00
|
|
|
|
|
|
|
batchOnly :: Maybe KeyOptions -> CmdParams -> Annex () -> Annex ()
|
|
|
|
batchOnly Nothing [] a = a
|
|
|
|
batchOnly _ _ _ = giveup "Cannot combine batch option with file or key options"
|
|
|
|
|