Create a Post
Showing results for 
Search instead for 
Did you mean: 

cpview -t command line arguments changed between R80.20 and R80.30

A minor point of frustration...

Can anyone explain why Check Point changed the command line options of cpview between R80.20 and R80.30 (sk101878)?

Specifically, in R80.30 it is no longer possible to specify the 'start date' when using cpview in historic mode (cpview -t).

In R80.20 you can specify that start date as '-t <timestamp>'. In R80.30, the -t option no longer accepts the <timestamp> and you will have to type (shift?) t to enter that timestamp manually. This change of behaviour breaks my scripts (automatic startup of cpview at a specified time in the past).

As a generic complaint: I have noticed several other command line utilities over time, changing their behaviour in such a way that these options are NOT backward compatible with older versions. In my humble opinion, this is considered bad programming behaviour. Not only do such changes break existing scripts, it also makes it confusing for customers: when you find an example of a utility on the Internet (forum, Check Point documentation, even older sk-articles) it is never clear which version of the utility is being used. That information becomes out of date very soon, if existing behaviour changes.

Newer versions of utilities may introduce NEW command line options, but they should NEVER change existing behaviour, unless backward compatibility is preserved.

Your opinion please...

3 Replies


The change you are referring to was made in an attempt to simplify the usage of cpview.

I understand and sympathize with what you are saying - we should not break existing flows unless absolutely necessary. Your scripts breaking is proof of that.

I don't think that returning the old behavior is the best course of action, but I can share some good news on this regard - we are working to add better command-line capabilities to cpview, so that in the future you will be able to get any data you need from it by using a simple command, and you would get back a well-formatted response (one that you can use in scripts and know that it will not be broken in the future).

At the moment I can't share exactly when this new feature will be ready, except to say that we are working on it.

0 Kudos

This removal of the option also causes me some frustration when using cpview. I am really looking forward for the promised extended cpview CLI interface.

It is certainly good to allow interactive jumping to a given datetime but the CLI option was much mode useful for me:

* usable with CLI editing

* usable with CLI history and shell substitutions

* the CLI history helps a lot because it is difficult for me to remember the weird accepted strict format of datetime as the most basic format (ISO 8601) is not understood by cpview

* usable for shell scripting

It would also be great if you can release the cpivew client (just for browsing the sqlite database) to be installable in major Linux distributions (not just Gaia).

Another example of a very unfriendly tool which has only interactive interface (no CLI) is lvm_manager. In my opinion all tools should have at least a basic CLI interface in the first place then the interactive interface could be implemented.


These are good points, and I will take them into consideration for our next developments in CPview and related products.


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events