Is it possible to list all variables (print symbol table) in bc command?
For example
$ bc -q
x=3
y=4
z=x+y
/* a command for listing all variables defined */
/* and it will show:
x 3
y 4
z 7
or maybe in other format */
If saying "all defined variable" is ambiguous, "all non-zero variables" should also be acceptable.
No, no such command exists in bc.
Related
The local system datetime is 10:34 PM 1/8/2021.
In Stata I write
local datestamp: di %tdCCYY-NN-DD daily("S_DATE","DMY")
display `datestamp'
and the output is 2012
If I write
di %tdCCYY-NN-DD daily("S_DATE","DMY")
I get 2021-01-08
Why the discrepancy? This is puzzling to me. I clearly assigned datestamp yet when I display it obviously something is wrong.
Executive summary: display saw 2021-01-08 and evaluated it as a expression in numbers. 2021 - 1 - 8 = 2012, so 2012 was what you saw.
This is a subtle question, but the answer will show Stata's perfect logic, by its own rules.
The code as posted in the question omits the crucial $ sign before S_DATE, which indicates a global macro, specifically a system macro containing the current daily date, obtained from your operating system.
It is now 9 January 2021 in my time zone, but my example will work as well as yours to show what is going on. You defined a local macro, and then you included a reference to that local macro in a call to display. The display command has a designed inclination to calculate the result of any expression it sees before it displays the result of that calculation.
Taking this more slowly: There are two quite distinct steps to the interpretation of your display command. First, as a matter of interpreting any Stata command line, all references to local and global macros are replaced with the contents of those macros (if they exist; it is not an error to refer to a macro that does not exist, but that is not an issue here). Second, display evaluates any expression it sees and then displays the result of that expression. Despite its name, display is not designed to show you directly any macro that exists, although that is what happens if the result of evaluating it leaves it the same as when it was presented. Thus if a local macro contains the string foo, that is what display will show you -- unless foo is the name of a scalar or variable, in which case the name won't be shown, just the values of that scalar or that variable (in the first observation, in the latter case).
The command to see exactly what is inside a macro, without interpretation or calculation, is macro list.
To the point, consider the different results here. In the first display command, the quotation marks " " are functional, not ornamental, and instruct display to treat its input as a string. Without the quotation marks, display is inclined to treat what it sees as numeric, and here it sees an expression, 2021 MINUS 1 MINUS 9, which evaluates to 2011. The leading zeros are ignored. In your case your date was 2021-01-08 and the result was 2012, as you reported.
. local datestamp: di %tdCCYY-NN-DD daily("$S_DATE","DMY")
. di "`datestamp'"
2021-01-09
. di `datestamp'
2011
You get the right answer with the last statement in your question. You fed display a number but instructed it to use a daily date display format to interpret that number, and you got exactly what you asked for and you expected. 22288 is, or was, 8 January 2021 on scale with origin 0 at 1 January 1960.
This question already has answers here:
Brace expansion with a Bash variable - {0..$foo}
(5 answers)
Closed 3 years ago.
If I run this command in a shell with static values (i.e., 27..97), it works fine and gives the desired output
>ls -d $WORKDIR/batch/somefilename_{27..97}.* 2>/dev/null
somefilename_27.sometxt
somefilename_28.sometxt
somefilename_29.sometxt
..
somefilename_97.sometxt
But if I want to include variables or pass arguments to regular expression then I get the error
ls: cannot access /home/work/batch/somefilename_{27..96}.*: No such file or directory
But that’s not true because the file is present but somehow with variables the regex is not working.
>segStart="27"
>segEnd="96"
>myvar="$segStart..$segEnd"
>echo $segStart
27
>echo $segEnd
96
>echo $myvar
27..96
ls -d $WORKDIR/batch/somefilename_{$myvar}.*
"ls: cannot access /home/work/batch/somefilename_{27..96}.*: No such file or directory"
>array=($(ls -d $WORKDIR/batch/somefilename_$myvar.* 2>/dev/null))
>len=${#array[*]}
>echo $len
0
Note: I am trying to store in an array the directory names where the name is between two integers: e.g., there are 1-100 directories available with name file_1.some, file_2.some, file_3.some, … file_100.some.
If a user wants to get directories from 47 till 97, then I want to read those numbers, store them, and pass them in above ls command.
If you have any other alternative that will also help.
Brace expansion and globbing are very different from regular expressions
Brace expansions happen at defined places in the shell grammar (not in quotes or after parameter expansion; see man bash)
Please don’t use ls to get a list of files in an array: the following should work just fine
arr=(path{1..10}*)
Or, arr=(path*) and then you can filter by testing with [[ the ones you want to get rid of.
You can use seq command to accomplish this:
ls -d $WORKDIR/batch/somefilename_$(seq $segStart $segEnd).*
If you start from 1 for example and want to have it with leading zero (01) you can use formated output of seq like this:
seq -f "%02.0f" $segStart $segEnd"
New to SAS. I know the following codes are creating a macro variable that stores a list of variables names, but what do : and | mean?
%let v_lst = a b bb: t_v129 |
c tt: t_v16 t_v275 |
d: t_v56 |
;
The bar | has no fixed meaning. It is probably used as a delimiter. The macro variable is later split in subtrings delimited by |. This is often done using the %scan function and represents a way of list processing.
The colon indicates a prefix. bb: - all variables starting with bb. Many SAS PROC and the datastep can process variable lists this way.
You can put anything in macro variables, and what counts is what you do with it next. Now as a convention, the | symbol is conveniently used as a field/value separator, while the colon has no clear "conventional" use that I know of. Depending on the context, it could mean that values on its left (columns/variables) are to be associated to values to its right (other columns maybe). But you'd really need to look further down the code and look for loops using &v_lst, probably along with scan() or %scan() functions.
I would like to enter groups of variables into a Stata command, but can't find a way to do so.
E.g. In a factor analysis, with a set of 41 variables, I would like to exclude the 5th, 33rd and 35th, but include the rest.
Should it be something like: factor x1-x4, x6-x32, x34, x36-41, factors(5) pcf
Your example calls up a factor analysis. Let''s keep with that. If your variables are indeed at least those named out of x1 through x41 then
factor x1-x4 x6-x32 x34 x36-x41
could be legal. Note that (1) the commas are not included; (2) the last varlist was corrected, as x36-41 could never be a legal varlist (as 41 could never be a legal varname); and (3) when two or more variable names are joined with a hyphen, here x6-x32 and x36-x41, such a varlist indicates a block of variables in the current dataset order, not necessarily all variables whose names begin with x with implied suffixes, e.g. in 36(1)41. Thus x36-x41 could mean x36 frog toad x41 if you have variables with those names in that order.
The moral is simple: have your variables in an order that makes management and analysis simple and easy to think about. The order command provides the easiest way to change variable order programmatically.
The more general problem of removing variable j in order from an arbitrary varlist seems a little artificial, but here we go. Suppose we have a list of variable names (in fact any names) in a local macro. tokenize maps them one by one to local macros numbered 1 up, after which we can remove whatever we like. In the example below the output of mac li is edited to remove stuff irrelevant to this example, which could be quite a lot.
. local varlist foo bar bazz frog toad newt whatever
. tokenize `varlist'
. mac li
_7: whatever
_6: newt
_5: toad
_4: frog
_3: bazz
_2: bar
_1: foo
_varlist: foo bar bazz frog toad newt whatever
. foreach j in 1 3 5 {
2. local varlist : list varlist - `j'
}
. mac li
_varlist: bar frog newt whatever
_7: whatever
_6: newt
_5: toad
_4: frog
_3: bazz
_2: bar
_1: foo
For other methods of manipulating lists, see help macrolists.
I came across a little puzzle with Stata's locals, display, and quotes..
Consider this example:
generate var1 = 54321 in 1
local test: di %10.0gc var1[1]
Why is the call:
di "`test'"
returning
54,321
Whereas the call:
di `test'
shows
54 321
What is causing such behaviour?
Complete the sequence with
(1)
. di 54,321
54 321
(2)
. di "54,231"
54,321
display interprets (1) as an instruction to display two arguments, one by one. You get the same result with your last line as (first) the local macro test was evaluated and (second) display saw the result of the evaluation.
The difference when quotation marks are supplied is that thereby you insist that the argument is a literal string. You get the same result with your first display command for the same reasons as just given.
In short, the use of local macros here is quite incidental to the differences in results. display never sees the local macro as such; it just sees its contents after evaluation. So, what you are seeing pivots entirely on nuances in what is presented to display.
Note further that while you can use a display format in defining the contents of a local macro, that ends that story. A local does not have an attached format that sticks with it. It's just a string (which naturally may mean a string with numeric characters).