Re: [Sccs-devel] SCCS keyword expansion issue
The UNIX Source Code Control System activelty maintained/enhanced
Brought to you by:
schily
From: Jonathan L. <jon...@gm...> - 2018-08-02 03:38:44
|
The classic technique, which I used extensively before I (reluctantly) switched to RCS before the Y2K 'crisis', was to use extra quotes to break up the strings that could be identified as SCCS keywords. For example, something along the lines of: DATE=$(date +'%Y''%m%d-%H''%M''%S') That replacement uses $(…) in preference to `…`; it also uses single quotes around the whole format string, and then within the string, uses adjacent single quotes (not double quotes) to separate %M, %H or %Y from the following %, etc. This requires no changes to SCCS; it merely requires care when writing the script. Because my current code is mainly stored in RCS, I no longer have to worry as much about that (there are other problems instead), but I found a pair of scripts in my bin directory: isodate:fmt_c="%Y%m%d.%H%M%S" # Compact -- Beware SCCS prodverstamp:else PRODVRSN="${BASEVRSN}.`date +%Y%m%d`" # Beware SCCS! These are not protected from SCCS, but I have still noted that SCCS could screw them up. The earliest version of both those files is after 2000. I didn't find a pre-Y2K script that used any variation on the technique because I didn't use the date formatting options in date all that often back then. Eventually I found an alternative, but roughly equivalent, technique: RCS/build.ids.sh,v:tag=`date +JL-"%Y"%m"%d"."%H"%M"%S"` # SCCS! This uses pairs of double quotes around `%X` units within the format string (and the earliest version dates back to 2004). All the examples are from my private set of scripts. They have more or less inscrutable purposes. On Wed, Aug 1, 2018 at 4:43 PM thinkunix <thi...@zo...> wrote: > Hi, > > I have been using Schily SCCS for a while and it has worked > great. Recently I ran into an issue with ID keyword expansion. > > I have a shell script which is setting a variable using the > date(1) format controls, like so: > > ....................cut here.................... > : > # datestring.sh > #ident %W% %E% %U% %Q% > # > > DATE=`date +%Y%m%d-%H%M%S` > echo "DATE = [$DATE]" > ....................cut here.................... > > I check it into SCCS then check out a read-only copy which > will have the ID keywords expanded using the following sequence: > > $ admin -idatestring.sh -y'initial version' s.datestring.sh > $ rm datestring.sh > $ get s.datestring.sh > 1.1 > 7 lines > > > The problem is the multiple '%' chars in the date(1) command > are being expanded as though they were SCCS ID keywords. > Obviously, this breaks the shell script. > > $ cat datestring.sh > > ....................cut here.................... > : > # datestring.sh > #ident @(#)datestring.sh 1.1 18/08/01 19:13:22 > # > > DATE=`date +m%d-08/01/18M%S` > echo "DATE = [$DATE]" > $ sh ./datestring.sh > DATE = [m01-08/01/18M35] > ....................cut here.................... > > > Historically date(1) lacked format strings, e.g. "+%Y%m%d", > so this was never an issue. > > I tried "get -k" but that prevents expanding _ALL_ SCCS ID keywords, > and I do want them for revision identification. > > I am running Slackware 14.2 on x86 with SCCS version: > admin schily-SCCS version 5.05 2011/10/01 (i686-pc-linux-gnu) > > I also tried: > admin schily-SCCS version 5.08 2015/09/05 (i686-pc-linux-gnu) > > with the same results. > > Any suggestions on how to work around this? > > I could call date(1) multiple times and build up the date string > but that seems wasteful. Something like this: > > YEAR=`date +%Y` > MONTH=`date +%m` > DAY=`date +%d` > ... > > TODAY="$YEAR$MONTH$DAY..." > > thanks, > scot > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Sccs-devel mailing list > Scc...@li... > https://lists.sourceforge.net/lists/listinfo/sccs-devel > -- Jonathan Leffler <jon...@gm...> #include <disclaimer.h> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." |