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
|
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, batchmode@(Batch fmt), _) =
|
2020-04-15 20:04:05 +00:00
|
|
|
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
|
|
|
|
BatchNull -> splitc '\0'
|
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 ->
|
|
|
|
let f' = toRawFilePath f
|
|
|
|
in ifM (matcher $ MatchingFile $ FileInfo f' f' Nothing)
|
|
|
|
( a (si, Right f')
|
|
|
|
, 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) ->
|
|
|
|
Right . Right . fromRawFilePath
|
|
|
|
<$$> 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
|
|
|
|
Right bf -> flip whenAnnexed bf $ \f k ->
|
|
|
|
checkpresent k $
|
|
|
|
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
|
|
|
|
}
|