Proposal for uname / cvs

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for uname / cvs

Uwe Dippel
I happen to have more and more systems that identify as
$ uname
OpenBSD
which is good. One way or another.

One item that tends to go wrong here is cvs, where I have some scripts
doing cvs regularly, and I lose track of the version while
upgrading by re-using the scripts.
In cvs it is OPENBSD_4_0 as of now, while
$ uname -sr
OpenBSD 4.0
, so that I can't use the otherwise very helpful utility (uname) out of
the box.

I think the objective is clear: Instead of re-learning my cvs-commands or
modifying all those scripts, on a long run, it would be great to migrate
cvs to understand something like:
cvs -a -b [hidden email]:/cvs  -r `uname -sr`-d
or add an option to uname:
cvs -a -b [hidden email]:/cvs  -r `uname -c[vs]`-d
where
$ uname -c
returns
OpenBSD_4_0
(or anything likewise).

I am convinced that it will help a lot of people if we had a
placeholder for details of the underlying system when using cvs in a
straightforward manner [or cvs readily accepting the existing ones].

My excuses, if it exists.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Jasper Lievisse Adriaanse
Are you afraid of unleasing the powers of sed(1)?

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Darrin Chandler
In reply to this post by Uwe Dippel
On Sat, Dec 09, 2006 at 05:23:19PM +0800, Uwe Dippel wrote:

> I happen to have more and more systems that identify as
> $ uname
> OpenBSD
> which is good. One way or another.
>
> One item that tends to go wrong here is cvs, where I have some scripts
> doing cvs regularly, and I lose track of the version while
> upgrading by re-using the scripts.
> In cvs it is OPENBSD_4_0 as of now, while
> $ uname -sr
> OpenBSD 4.0
> , so that I can't use the otherwise very helpful utility (uname) out of
> the box.
>
> I think the objective is clear: Instead of re-learning my cvs-commands or
> modifying all those scripts, on a long run, it would be great to migrate
> cvs to understand something like:
> cvs -a -b [hidden email]:/cvs  -r `uname -sr`-d
> or add an option to uname:
> cvs -a -b [hidden email]:/cvs  -r `uname -c[vs]`-d
> where
> $ uname -c
> returns
> OpenBSD_4_0
> (or anything likewise).
>
> I am convinced that it will help a lot of people if we had a
> placeholder for details of the underlying system when using cvs in a
> straightforward manner [or cvs readily accepting the existing ones].
>
> My excuses, if it exists.
>
> Uwe

uname -sr | tr '[:lower:] .' '[:upper:]_'

Somehow I think changing scripts is a better solution in this case. Or
copy the above into a new script named uname-cvs. ;)

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Uwe Dippel
On Sat, 09 Dec 2006 02:46:34 -0700, Darrin Chandler wrote:

> uname -sr | tr '[:lower:] .' '[:upper:]_'
>
> Somehow I think changing scripts is a better solution in this case. Or
> copy the above into a new script named uname-cvs. ;)

Thanks Darren, but I'd written this myself faster than it took me to write
the message. I am still sure, that most users, including writers (and
updaters) of the FAQ would profit from this addition. The FAQ is full of
this `arch`, `uname` `machine` and whatnot stuff.
When you read through the cvs chapters, there is always the explicit
OpenBSD_V_n.

There is a German proverb that expresses something like 'Why make it
simple, when can be done in a complicated way as well ?'

If what you propose finds entry into the system, fine. Because me and
everyone else will have it readily available for the next system to
install, and Copy&Paste a command from http://www.openbsd.org/anoncvs.html
or the FAQ; to be used freely, immediately, and in scripts and
without the need to additionally obtain or create this simplification.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

jared r r spiegel
On Sat, Dec 09, 2006 at 07:04:22PM +0800, Uwe Dippel wrote:

>
> Thanks Darren, but I'd written this myself faster than it took me to write
> the message. I am still sure, that most users, including writers (and
> updaters) of the FAQ would profit from this addition. The FAQ is full of
> this `arch`, `uname` `machine` and whatnot stuff.
> When you read through the cvs chapters, there is always the explicit
> OpenBSD_V_n.
>
> There is a German proverb that expresses something like 'Why make it
> simple, when can be done in a complicated way as well ?'

  rather than adding bloat to uname(1) (that other OSs aren't going to have),
  just write a simple function in the script that checks for existance
  of 'CVS/Tag' - assumes 'HEAD' if missing, otherwise reads it in and knocks
  the first character off.

  that's easy to write in a manner such that users of several OSs and
  various shells could just copy/paste and have it work for them too.

--

  jared

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Igor Sobrado
In reply to this post by Uwe Dippel
Hi Uwe.

I see the advantages of your proposal but, as suggested in this thread
and as you did, sed(1) can be very helpful in this matter.  Just my
opinion, but one of the best features in the BSD family of operating
systems is that these operating systems are simple.  The BSD operating
systems do not have the overfeaturism we can find in other OSes these
days (sadly, Linux and Windows are not the only examples right now).

In my humble opinion, it is better translating the output of uname(1)
to the format required by cvs by means of sed(1).  What if developers
choose to tag the branches in a different way?

A small sed(1) expression to translate lowercase letters to uppercase
letters and adding the required underlines is probably easier to read
for someone with certain Unix knowledge than a non-standard option added
to uname(1).

And yes... I am against the "-z" and "-Z" options in tar(1), and the
"-t" option in spell(1).  The latter is even worse.  These options can
not only be replaced with a pipe to, we say, the compression tools (in
the case of gzip(1) we have even more options available in this way)
but the filter to remove TeX commands from the source in spell(1) is
not in the base system (and should not be... except if TeX is part of
the base system, and detex/delatex are not a part of any LaTeX
distribution I am aware of, it must be downloaded from a CTAN).

One of the goals of Unix (not only BSDs) was splitting complex tasks
in smaller tasks that can be efficiently done by the operating system.
Small tasks can be accomplished easily by these commands, larger ones
(like the one you describe) can be accomplished by a subset of the
commands, usually in one of the powerful scripting languages provided
with the operating system.  Overfeaturism addes superfluous complexity
to the operating system.

Just my opinion,
Igor.

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Uwe Dippel
On Sat, 09 Dec 2006 19:08:34 +0100, Igor Sobrado wrote:

> The BSD operating
> systems do not have the overfeaturism we can find in other OSes these
> days

Seems that it's about only me here who wants this simplification ... .
I fully agree with your arguments on
-possible change of tags
-optionbloat.
So I'll have an extra compatibility layer that translates the current
version to the current way of tagging.

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Igor Sobrado
In reply to this post by Uwe Dippel
Hi again, Uwe.

I think that I miss the point here.  For me, a compatibility layer is
making this model even more complex and, even worse, highly dependent
on the operating system release.  Changing the behaviour of uname(1)
just to track the current cvs repository seems overkill to me, but I
am in no way an expert.  If the development team changes the current
tagging scheme, this change will render that the behaviour of uname(1)
useless.

In my humble opinion, it is better providing a set of shell scripts
to do what you want by using the stream editor.  A good place to
provide these scripts to track branches would be the FAQ, I think.

On the other hand, Unix users love writing scripts (I certainly do!)
and awk(1), sed(1) and, sometimes, perl(1) are valuable tools.  There
is no need to make uname(1) more complex just to track cvs branches.
On the other hand, this change will help only when upgrading the
operating system source, it will be useless on any other scenario.

A shell script will be cleaner, easier to understand (al least for
people that has the ability to read these sed expressions) and will
not suppose a bottleneck in performance at all.

Best regards,
Igor.

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for uname / cvs

Darren S.
On 12/10/06, Igor Sobrado <[hidden email]> wrote:
> Hi again, Uwe.
>
> I think that I miss the point here.  For me, a compatibility layer is
> making this model even more complex and, even worse, highly dependent
> on the operating system release.  Changing the behaviour of uname(1)
> just to track the current cvs repository seems overkill to me,

Right. uname has a specific purpose, and needs to comply to POSIX.2.
It is not to provide a translation service for a syntax change to
support a very platform-specific CVS update procedure - that a
competent Unix admin would cough up in 3 seconds. Someone provided a
tr(1) syntax, others suggested sed(1), and the OS ships with Perl.
Whatever your preference, extending a basic Unix utility to perform
this pedantic format change is no justification.

DS