microsoft / cmd-call-graph Goto Github PK

It would be nice to visualize somehow the relationship between nodes from the point of view of number of lines of code. For example, have node size be proportional to the number of lines of code.

Python 2's EOL is at the end of 2019 (see https://legacy.python.org/dev/peps/pep-0373/). It does not make sense to keep supporting both Python 2 and 3: it would instead make sense to migrate the codebase to Python 3 and fully use the new features that recent versions of Python offer.

It might be useful to know how many terminating statements exists in a given terminating node.

As an example:

    goto :foo
    :foo
    exit

This snippet creates the following dot file:

digraph g {
__begin__ [label=<<b>__begin__</b><br />(line 1)>]
__begin__ -> foo [label=goto,color=red3]
__begin__ -> foo [label=nested,color=blue3]
foo [label=<<b>foo</b><br />(line 2)>,color=red,penwidth=2]
}

The connection of type nested is wrong, and should not be reported.

If a node has a name with percent signs in it, for example %command%, the dot program doesn't seem to like it, and outputs a garbage node with just a percent sign and a letter or number.

Figure out why that's the case, and fix it.

The color scheme today is rather primitive. It would be nice to have a better color scheme, with subtler and more thought-out colors.

Ideally, the output should not rely on colors only to convey information, to be more accessible (see https://usabilla.com/blog/how-to-design-for-color-blindness/).

We could extend the tool to follow calls to external batch scripts, and produce a larger call graph including a set of scripts.

There is already some primitive logic to identify external calls in CallGraph._AnnotateNode, as it generates Command instances of type external_call, but those commands are not processed in the later loop that goes through all Command instances. Therefore the logic to process external calls can be added to that loop.

What we can do there is simply call CallGraph.Build again to recursively generate another instance of CallGraph, that we would need to add to a container in the original CallGraph instance itself, keeping track of this new type of connection.

There are a few open questions that come to mind:

1. we need to handle recursion and not fall into the trap of infinite loops (for example, specifying a depth parameter to limit how deep we go in the chain of calls.
2. we need to de-duplicate call graphs for external batch files, so that if we call a given file multiple times we point to the same sub-graph.
3. we need to handle gracefully calls to non-batch files or files we don't want to expand (for example if we reached maximum depth). For example, by adding a single node for the file if we don't want or can't expand the given file
4. we need to decide how to visually represent the different files. For example, we could have rectangular enclosures around each batch file involved in the graph.
5. we may want to limit the set of files to expand (for example, only the ones belonging to a specific codebase). This might be achieved by specifying a set of files to expand as a command-line parameter.

The script currently considers the last node as a terminating node, no matter what.

In reality, the last node could contain, as a last statement, a goto which makes it not a terminating node.

Borkes when trying to parse https://github.com/nodejs/node/blob/master/vcbuild.bat, but that's not surprising.
I'll try to submit a PR later.

Instead of --show-node-stats=True, it would be nicer to just type --show-node-stats.

Example: when a batch file contains a line like this:

if foo==%var% (foo & goto :foo) ELSE (bar & goto :bar)

cmd-call-graph considers foo) and bar) as labels.

The rendered graphs often have different shapes. It would be nice to change the resulting dot code to always use the same ordering, if possible.

Also, it would be nice to have begin at the start and the terminating nodes at the end.

Some exit nodes are not detected by the current logic, which is rather primitive and looks at where the script ends, rather than exploiting the call graph.

For example, the script wouldn't recognize the bar node as the exit node in the following code:

goto :foo
:bar
exit /b 1
:foo
goto bar

The script was published "as-is", but for any further change, and to validate existing behavior, we really need to add some basic tests.

It would be nice to print:

• number of lines of code in the node;
• number of external calls in a node.

The description and the README say:

A simple tool to generate a call graph for Windows CMD (batch) files.

IMHO, it should read "for Windows CMD (batch) file."

The "files" suggest one can generate graph for batch scripts CALL-ing other batch scripts which, AFAICT, is not the case. Call graph can be generated for single batch file only.

Unit tests are failing, but the recent changes only touch README.md.

The error is the following:

2019-01-06T17:35:53.2926467Z =================================== FAILURES ===================================
2019-01-06T17:35:53.2930569Z ______________________ CodeLineTest.test_command_counters ______________________
2019-01-06T17:35:53.2933899Z 
2019-01-06T17:35:53.2940444Z self = <pytest_cov.plugin.CovPlugin object at 0x7f336dc97cd0>
2019-01-06T17:35:53.2950537Z item = <TestCaseFunction test_command_counters>
2019-01-06T17:35:53.2957731Z 
2019-01-06T17:35:53.2958299Z     @compat.hookwrapper
2019-01-06T17:35:53.2973012Z     def pytest_runtest_call(self, item):
2019-01-06T17:35:53.2989594Z >       if (item.get_marker('no_cover')
2019-01-06T17:35:53.2990087Z                 or 'no_cover' in getattr(item, 'fixturenames', ())):
2019-01-06T17:35:53.2990448Z E               AttributeError: 'TestCaseFunction' object has no attribute 'get_marker'

This seems to be related to a very recent change in pytest. From https://docs.pytest.org/en/latest/changelog.html#pytest-4-1-0-2019-01-05:

#4546: Remove Node.get_marker(name) the return value was not usable for more than a existence check. - pytest-dev/pytest#4546

The Keep a ChangeLog format has worked well for me in the past, let's adopt it.

Might require migrating tests to pytest.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

The tool can identify some flaws in batch files, for example goto / call to non-existing labels.

Implement a --lint option that only outputs potential problems with a given script.

It would be nice to run dot on Travis on the output of the tool, to verify that the dot code that it produces is readable by the dot tool.

All the options around getting a richer output should be enabled by default. That's how I mostly use the tool and there is no reason to disable them unless specifically desired by the user.

Also I think using stdin as input can be confusing (the tool just hangs if no input is given), so I'd change -i to be mandatory and possibly even positional instead of an argument.

Documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/pypi?view=vsts&tabs=yaml

• define what triggers publishing to PyPI
• define how to handle version numbers
• define how to handle the changelog
• handle authentication (https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/twine-authenticate?view=vsts)
• implement pushing to PyPI

A node can be both terminating and non-terminating, depending on how it's invoked.

If it's reached via goto or nested from a node that would have been terminating, it's terminating for that code path. But if it's reached via call from a non-terminating node, it's not terminating.

It would be nice to surface this information somehow. The easiest option might be a warning, not sure how to actually represent this case in the call graph.

It would be nice to run automated tests on Azure Pipelines instead of Travis.

Once that works, we could even automate publishing the build artifacts to PyPi.