Query(3pm)
π Term::Query π
okay bestie, pull up a chair and a lil snack because we're reading the Query(3pm) page together, from the User Contributed Perl Documentation. it's giving "old-school Perl module that does way more than you think", and honestly? it ate. π
β¨ NAME β¨
Term::Query β a table-driven query routine. that's it, that's the name, no notes. π
π¦ SYNOPSIS π¦
"use Term::Query"
"qw( query query_table query_table_set_defaults
query_table_process );"
"$result = query $prompt, $flags, [ $optional_args ];"
"$ok = query_table \@array;"
"query_table_set_defaults \@array;"
"$ok = query_table_process \@array, \&flagsub, \&querysub;"
look at those quotes. iconic behaviour honestly. π
π DESCRIPTION π
π query
the query subroutine is here to fulfill the need for a generalized question-response subroutine, and it comes with programmatic defaulting, validation, condition and error checking. so basically it's the whole package. π«Ά
you hand it $prompt and $flags, and possibly some additional arguments depending on what characters are chillin' in $flags. then query issues a prompt to STDOUT and solicits input from STDIN. that input gets validated against a set of test criteria as configured by the characters in $flags. if any of the tests fail, an error message is noted, and the query is reattempted. we try again, bestie. we always try again. π
important vibe check: when STDIN is not a tty (aka not interactive), prompts are not issued, and errors cause a return rather than attempting to obtain more input.
you can disable that non-interactive behaviour by setting the variable $Foce_Interactive as below:
$Term::Query::Force_Interactive = 1;
when $Force_Interactive is a non-null, non-zero value, query will issue prompts, error messages, and ask for additional input even when the input is not interactive. π
(yeah, the page spells it $Foce_Interactive in one spot and $Force_Interactive in the next. not me noticing. anyway, moving on. π)
π§ query_table
the query_table subroutine performs multiple queries by invoking query, and it sets associated variables with the results of each query. the prompts, flags, and other arguments for each query are given in an array β called a query table β which is passed to the query_table subroutine by reference. slay.
πΈ query_table_set_defaults
the query_table_set_defaults subroutine causes any variables named in the given query table array to be assigned their corresponding default values, if any. this is a non-interactive subroutine. no chatting, just assigning. β¨
π query_table_process
a general interface to processing a query table is available with the query_table_process subroutine. it accepts a query table array, and two subroutine references: a &flagsub and a &querysub. the &flagsub is invoked on each each flag character given in the $flags argument of the query table (see below). the &querysub is invoked for each query in the query table. π¦
the query_table and query_table_set_defaults subroutines both use query_table_process to perform their functions. main character energy all the way down. π
π Query Table
the format of the query table array passed to query_table, query_table_set_defaults, and query_table_process subroutines is:
@array = ( $prompt1, $flags1, [ $arglist1, ... ],
$prompt2, $flags2, [ $arglist2, ... ],
...
$promptN, $flagsN, [ $arglistN, ... ] );
in English: there are three items per query β a prompt string, a flags string, and an array of arguments. β
heads up, bestie: the syntax used above uses [ ... ] to denote a Perl 5 anonymous array, not an optional set of arguments. don't let it gaslight you.
of course, if there are no arguments for a particular query, the corresponding anonymous array can be the null string or zero. easy.
the query table design is such that a query table can be created with a set of variables, their defaults, value constraints, and help strings, and it can be used to both initialize the variables' values and to interactively set their new values. the query_table_set_defaults subroutine performs the former, while query_table does the latter. two jobs, one table, we love efficiency. π
π Flag Characters
with typical usage, given $prompt and $flags, query prints $prompt and then waits for input from the user. the handling of the response depends upon the flag characters given in the $flags string. π«Ά
the flag characters indicate the type of input, how to process it, acceptable values, etc. some flags simply indicate the type or processing of the input, and do not require additional arguments. other flags require that subsequent arguments to the query subroutine be given. the arguments must be given in the same order as their corresponding flag characters. π
the ordering of the flags in the $flags argument is important β it determines the ordering of the tests. for example, if both the a and m flags are given as "am", then this indicates that an after subroutine call should be performed first, followed by a regular expression match test. order matters, periodt. π
all tests are applied in the order given in the $flags until a particular test fails. when a test fails, an error message is generated and the input is reattempted, except in the case of the I flag. noted. π
β¨ Flag Characters Without Arguments β¨
iβ the input must be an integer. π’nβ the input must be a number, real or integer.Yβ the input is a"yes"or"no", with a default answer of"yes". βNβ the input is a"yes"or"no", with a default answer of"no". πrβ some input is required; an empty response will be refused. this option is only meaningful when there is no default input (see thedflag character below).sβ strip and squeeze the input. leading and trailing blanks are eliminated, and embedded whitespace is"squeezed"to single blank characters. this flag is implied by thekandKflags. π§ΉHβ do not treat input of?as a request for help. this disables automatic help, unless implemented with the after (aflag) subroutine. π
π Flag Characters With Arguments π
the following flag characters indicate the presence of an argument to query. the arguments must occur in the same order as their corresponding flag characters. for example, if both the V and h flags are given as "Vh", then the first argument must be the variable name, and the next the help string, in that order. π
a\&afterβ the next argument is the after subroutine, to be invoked after the input has been solicited. this feature provides for an"open ended"input validation, completely at the control of the user of the Query module. the after subroutine is invoked in this manner:
&$after( \$input );
if the after sub returns an "undef", then query processing stops with an immediate "undef" return value.
if the after sub returns a null or zero value, then the input is rejected and resolicted. no error messages are displayed except the "Please try again." message.
since the after sub has the reference to the $input variable, it is free to change the value of input indirectly; ie:
$$input = $some_new_value;
b\&beforeβ the next argument is the before subroutine, to be invoked before any input is attempted. if the before sub returns a non-null, non-zero value, the current query will be attempted. if a null or zero value is returned, the current query will be abandoned, with a null return.
this feature, used in a query table, allows for selective queries to be programmed by using before subs on the optional queries. for example, using the following anonymous sub as the b flag argument:
sub { $> == 0; }
will cause the corresponding query to only be issued for the "root" user. π
the ordering of the b flag in the $flags argument is unimportant, since, by definition, this test is always performed before attempting any input. π¦
d$defaultβ the next argument is the default input. this string is used instead of an empty response from the user. the default value can be a scalar value, a reference to a scalar value, or a reference to a subroutine, which will be invoked for its result only if a default value is needed (no input is given). βh$help_stringβ the next argument is the help string, which is printed in response to an input of"?". in order to enter a?as actual text, it must be prefixed with a backslash:"\?". πk\@arrayβ the next argument is a reference to an array of allowable keywords. the input is matched against the array elements in a case-insensitive manner, with unambiguous abbreviations allowed. this flag implies thesflag.
the matching can be made case-sensitive by setting the following variable prior to the invocation of query:
$Query::Case_sensitive = 1;
by default, this variable is null. π
K\@arrayβ the next argument is a reference to an array of disallowed keywords. in this case, for the input to be unacceptable, it must match exactly, case-insensitive, one of the array elements. this flag implies thesflag.
the k option is useful for soliciting new, unique keywords to a growing list. adding new fields to a database, for example. ποΈ
the matching can be made case-sensitive by setting the $Query::Case_sensitive variable (see above).
l$maxlenβ the next argument specifies the maximum length of the input. πm$regular_expressionβ the next argument specifies a regular expression pattern against which the input will be matched. πI$referenceβ the next argument is the input: either a simple scalar value, or a reference to a value, such as a"SCALAR"variable reference (eg:"\$somevar"), or a"CODE"reference (eg:"sub {..}"). in any case, the resulting value is used as input instead of reading fromSTDIN.
fr fr pay attention: if the input returned by the reference does not match other constraints, additional input is not attempted. an error message is noted, and an "undef" return is taken.
this option is handy for applications which have already acquired the input, and wish to use the validation features of "query". π
it is also useful to embed a query definition in a query table which does not actually perform a query, but instead does a variable assignment dynamically, using the I reference value. β¨
J$referenceβ the next argument is the input reference, as with theIflag, except that if the input fails any of the constraints, additional input is solicited from the input. in other words, theJflag sets a one-time only input reference. think of it as jumping into the query loop with an initial input. πββοΈπ¨Vvariable_name_or_refβ the next argument is the variable name or reference to receive the validated input as its value. this option, and its corresponding variable name, would normally be present on all entries used withquery_tablein order to retain to the values resulting from each query.
the value can either be a string representing the variable name, or a reference to a variable, eg: "\$some_var". π«Ά
β¨ Details β¨
okay so the tea is: query runs its checks basically in the same order you listed the flags in the flags argument β with some exceptions. Like, the before subroutine is always done before input. always. no skipping. π
There are also sneaky implicit precedences in the ordering of some flag tests. Generally, each flag's test happens in the same order as the given flags. But some flag tests need other flags' tests to run first to even be effective. Example bestie: when you give the k flag and an s flag, stripping the input would only work if the strip happens on the input before testing it against the keyword table. In other words, s has precedence over k. So if you hand over the flags string as "ks", the effective ordering is still "sk". the math is mathing β¨
Here's the precedence chart of the flag tests:
i(int) β flags with higher precedence:s(strip),d(default),h(help)k(key) β flags with higher precedence:s(strip),d(default),h(help)K(nonkey) β flags with higher precedence:s(strip),d(default),h(help)l(maxlen) β flags with higher precedence:d(default),h(help)m(match) β flags with higher precedence:d(default),h(help)n(numeric) β flags with higher precedence:s(strip),d(default),h(help)N(no) β flags with higher precedence:s(strip),d(default),h(help)r(required) β flags with higher precedence:d(default),h(help)s(strip) β flags with higher precedence:d(default),h(help)Y(yes) β flags with higher precedence:s(strip),d(default),h(help)
Other than the implied precedence in the chart above, the ordering of the flag tests goes in the same order as given in the flags argument. fr fr.
So, aside from those precedences, query processing goes generally like this:
- If the
bflag was given, the"before"subroutine is invoked as a"pre-input"test. If the sub returns a0, empty string, orundef, the query is abandoned. Otherwise, processing continues. - If the
IorJflags were given, then input is obtained, without prompting, from the associated reference. If the reference type is"CODE", then it gets invoked and the resulting return value is used as the input. Otherwise the reference is evaluated in a scalar context and used as the input. TheJflag test is only done once, on the first entry into the input loop. one and done π«Ά - In the absence of either the
IorJflags,"query"will issue the given prompt and get input fromSTDIN. If anEOFhappens, an"undef"value is the result. - The input gets examined for
"null"input (aka the empty string), and processing quits in that case. Since most input comes fromSTDIN, a null input means an end-of-file (EOF). If the input is not null, a terminating newline is removed, and the input testing continues. At this point, an empty input string does not mean an EOF. important distinction bestie. - If the
s,k, orKflags were given, the input gets trimmed of leading and trailing blanks, and all whitespace is"squeezed"to single blanks. - If the input is an empty response, and there's a default input (the
dflag), use that instead. - Unless the
Hflag is given, if the input is the character"?"with nothing else, then some helpful info gets printed. If the user supplied a help string, that gets printed; otherwise the message:
You are being asked "$prompt"
is displayed. Also, some info about the expected response β according to any given flag characters β is displayed. Finally, the user gets sent back to the prompt, and gets another opportunity to enter a response.
- If input is required (that's the
rflag), and if the input is empty, produce an error message, and query again. - If there was an
aflag, the corresponding after subroutine is invoked with the input reference as its argument. If the subroutine returns a non-null, non-zero value, the input succeeds; otherwise it fails. It's up to the after subroutine to display any appropriate error messages. - If the query was flagged
YorN, match the input against the pattern:
/^(y(es?)?|no?)$/i
If the match fails, print an error message, and query again. When the match succeeds, replace the input with the complete word "yes" or "no";
- If an integer response is required (
iflagged), check for integer input. If it's not an integer, print an error, and query again. A successful integer input is returned. - If a numeric response is required (
nflagged), check for proper numeric input (either integer or real format). Errors produce a warning, and another query. - If the query was given a keyword table (flagged with
k), the input is matched against the allowable keyword list. If an exact match is found, the keyword is returned as the input. Failing an exact match, an abbreviation search is performed against the keywords. If a single match is found, it's returned as the input. If no match is found, an error message is produced, and the user gets returned to the query to try again. Otherwise, the input was ambiguous β an error gets noted showing the matches, and the user is queried again.
The matching is case-insensitive or not, according to the value of the variable $Query::Case_sensitive, which is nil by default. The variable may be set by the user to change the matching from case-insensitive to case-sensitive.
- If the query was given an unacceptable keyword list (flagged with
K), the input is compared against the unacceptable keywords. If it matches any keywords exactly, an error is noted, and the query is performed again.
The matching is case-insensitive by default. Set the variable $Query::Case_sensitive to a non-null, non-zero value to make the keyword matching case-sensitive.
- If the query was
mflagged with a Perl regular expression pattern, then the input is matched against the pattern. Failures get noted with an error message, and the query reattempted. - If the query was
lflagged with a maximum input length, the length of the input is checked against the maximum. A length violation gets noted with an error message and the user is queried again. - If the query has a variable defined with the
Vflag, the variable is assigned the input string. This is always done last, after and only if all tests are successful. π
If the variable is a string name and not qualified with a package name (ie: $foo::variable), then the variable is qualified at the level outside of the Query.pm module.
- Finally, having passed whatever conditions were flagged, the input is returned to the user. slay. β¨
πΈ EXAMPLE πΈ
Here are some typical usage samples:
- To perform a simple
"yes"or"no"query, with"no"as the default answer:
$ans = &query("Do you wish to quit? (yn)",'N');
- An equivalent alternative is:
query "Do you wish to quit? (yn)", 'NV', \$ans;
- To perform the same query, with some supplied helpful information:
$ans = &query("Do you wish to quit? (yn)",'Nh',<<'EOF');
You are being asked if you wish to quit. If you answer "yes",
then all changes will be lost. An answer of "no", will allow
you to return to continue making changes.
EOF
- To solicit an integer input:
$mode = &query("Please enter the file mode:",'idh','644',<<'EOF');
Please enter the 3 digit numeric file mode; if you are unsure
of how the file mode is used, please see the man page for "chmod".
EOF
- To solicit one of several keywords:
@keys = split(' ','SGI DEC IBM Sun HP Apple');
$vendor = &query('Please enter a vendor:','rkd',\@keys,'SGI');
- To solicit a new, unique keyword to be used as a database field name, with a regexp pattern to check it against:
@fields = split(' ','Index Vendor Title'); # existing fields
$newfield = &query('New field name:','rKm',\@fields,'^\w+$');
π ENVIRONMENT π
COLUMNSβ This variable is used to control the width of output when listing the keyword arrays. If it's not defined,80is used by default.
π§ DEPENDENCIES π§
Carp.pmβ Used to produce usage error messages.Array::PrintCols::print_colsβ Used to produce displays of the keyword arrays.
π FILES π
None. that's it bestie, nothing here π
π AUTHOR π
Copyright (C) 1995 Alan K. Stebbins <aks@hub.ucsb.edu>
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
okay so this is the part where the page talks back to you β every single way query can yell at your input, plus the very dramatic BUGS section. buckle up π
π DIAGNOSTICS π
Input is required.β you hit enter on an empty response and there's no default input to fall back on. bestie it's giving nothing, and Query is not impressed. πPlease answer with 'yes' or 'no', or enter '?' for help.β this one shows up onYorNflagged queries when your input just isn't reconizeable as a yes or a no. (yes, that's the spelling in the actual message, i don't make the rules π«Ά)Please enter an integer number.β printed the moment you give non-integer input to aniflagged query. whole numbers only, no decimals, no vibes. π’Please enter a number, real or integer.β printed when you give non-numeric input to annflagged query. real or integer, either is slay, but it has to be a number. β¨The input '$input' is ambiguous; it matches the following:β issued in response tokflagged queries when your input matches more than one of the allowed keywords. the$inputgets substituted in, and it lists out what it matched. πThe input '$input' fails to match any of the allowed keywords:β printed when the input to akflagged query matches none of the keywords. zero. nada. not one. πThe input '%s' matches a disallowed keyword '%s'.β printed when your input matches one of the unacceptable keywords you handed over on aKflagged query. you had ONE job. π'%s' fails to match '%s'β this one is the result of input failing to match the regular expression given on anmflagged query. regex said no. π§Input is %d characters too long; cannot exceed %d characters.β your input's length blew past the maximum length you gave with thelflag argument. too much main character energy for the box it's in. πΈPlease try again, or enter '?' for help.β yeah. this one just stands there on its own, offering you a second chance and a little help. π₯Ίquery: The k flag needs an array reference.β the next argument in the argument list toquerywasn't an array reference. it needed an array ref, it got something else, and it's telling you directly. π₯query: The K flag needs an array reference.β the next argument in the argumentlist toquerywasn't an array reference. same situation, capital-Kflavour. (yes, "argumentlist" is one word here β that's genuinely how it's written, no cap.) π
π³ BUGS π³
not a single bug listed. the section is literally just vibes and a blank space. iconic of it, honestly β no known bugs documented, nothing to warn you about, the page just closes the curtain. π
and that's the whole page, bestie!! π¦ this was Query(3pm) from perl v5.34.0, dated 2022-06-17 β go forth, prompt your users, and slay responsibly πβ¨ππ«Ά
π¦ where this page comes from
- debian bookworm: libterm-query-perl 2.0-11 Β· GPL-2.0-or-later
- debian trixie: libterm-query-perl 2.0-11 Β· GPL-2.0-or-later
- ubuntu noble: libterm-query-perl 2.0-11 Β· GPL-2.0-or-later
- ubuntu resolute: libterm-query-perl 2.0-11 Β· GPL-2.0-or-later
- ubuntu stonking: libterm-query-perl 2.0-11 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms