The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,317 other followers

Archive for December 17th, 2019

shell – Should I put #! (shebang) in Python scripts, and what form should it take? – Stack Overflow

Posted by jpluimers on 2019/12/17

It is very important to get the shebang correct. In case of Python, you both need env and the correct Python main version.

Answer

Correct usage for Python 3 scripts is:

#!/usr/bin/env python3

This defaults to version 3.latest. For Python 2.7.latest use python2 in place of python3.

Comment

env will always be found in /usr/bin/, and its job is to locate bins (like python) using PATH. No matter how python is installed, its path will be added to this variable, and env will find it (if not, python is not installed). That’s the job of env, that’s the whole reasonwhy it exists. It’s the thing that alerts the environment (set up env variables, including the install paths, and include paths).

Source: [WayBack] shell – Should I put #! (shebang) in Python scripts, and what form should it take? – Stack Overflow

Thanks GlassGhost and especially flornquake for the answer and Elias Van Ootegem for the comment!

The answer is based on [WayBack] PEP 394 — The “python” Command on Unix-Like Systems | Python.org.

The env is always in the same place, see env – Wikipedia and Shebang (Unix) – Wikipedia.

–jeroen

Posted in Development, Python, Scripting, Software Development | Leave a Comment »

InplaceExeWrapper for those tools that do not allow specifying an output file – twm’s blog

Posted by jpluimers on 2019/12/17

In my bin directory from [WayBack] InplaceExeWrapper Project Top Page – OSDN: [WayBack] InplaceExeWrapper for those tools that do not allow specifying an output file – twm’s blog:

There are a lot of command line tools that are very useful, but have one flaw: They directly modify a file in place and do not allow you to specify an output file instead.

…

Enter InplaceExeWrapper which called as

InplaceExeWrapper --expectfilenameonstdout c:\path\to\dprojnormalizercmd.exe input.dproj output.dproj

does the following:

  1. Create a temporary directory under %TEMP%
  2. Copy the input file input.dproj there
  3. Call the tool as dprojnormalizer tempfile.dproj
  4. Copy the modified file to the output file output.dproj
  5. Delete the temporary directory

So basically it replaces the missing functionality of specifying an output file for the tool it calls.

Here is the full help on command line parameters and options:

Synopsis: InplaceExeWrapper [options] Executable InFile [OutFile]

Parameters:
Executable        : Executable to call (if set to "copy" we only copy InFile to OutFile)
InFile            : input filename
OutFile           : output filename, defaults to infile

Options:
--CheckResult=value : If set, the executable must return the value given for this option (must be a number)
--debug           : if given, some debug output is written to error.txt in the temp directory and the temp directory will not be deleted.
--ExpectFilenameOnStdout : if set, the output of the executable must contain the filename
--help
-?
-h
-H                : display parameter help
--ShowCmdLine     : Show command line as passed to the program.
--StartupLog=value : Write a startup log to the given file.
--TempDir=value   : directory to use for temporary files (must exist)
--toStdOut        : if set, output is written to stdout and infile is not changed

Via [WayBack] There are a lot of command line tools that are very useful, but have one flaw: They directly modify a file in place and do not allow you to specify an o… – Thomas Mueller (dummzeuch) – Google+

–jeroen

Posted in Delphi, Development, Software Development | 2 Comments »

Delphi: “Override method %s.%s should match case of ancestor %s.%s (H2365)”

Posted by jpluimers on 2019/12/17

If you write consistent code, you will never see [WayBack] Override method %s.%s should match case of ancestor %s.%s (H2365), but a long while ago I bumped into a project where some the developers had trouble using their shift key and failed to use code completion in quite a few parts of the source code.

So next a lot of lines containing things like Begin, whIle, repeaT, wrong indentations (not just at the wrong level, but even getting things indented at the same level wrong).

Code formatted like this was no exception, not even for methods bound to events:

procedure  TForm1.Button1CLick(SendeR  : TOBJect ) ;
 Begin
  Button2Click  (Sender );
end;

You cannot disable this hint individually as it is not on the list at [WayBack] Delphi XE2’s hidden hints and warnings options | Marc Durdin’s Blog, so you either have to fix the code (which I prefer), or disable all hints with {$ HINTS OFF} as per [WayBack] compiler construction – Can specific Delphi hints be disabled? – Stack Overflow (thanks Lars Truijens).

The above occasion was the first and only time I saw the hint H2365 until recently when I again bumped into a project that had grown over a long time needing some maintenance.

This reminded me I should have blogged about it, found back [Archive.is] H2365 Override method %s.%s should match case of ancestor %s.%s (Delphi) Today was the first time I have ever seen this compiler hint. Why does Delphi… – Graeme Geldenhuys – Google+ and dug a bit deeper.

Read the rest of this entry »

Posted in Delphi, Development, Software Development | Leave a Comment »

 
<span>%d</span> bloggers like this: