mypath - Command line Tool für einfache PATH-Änderung auf Windows (Perl)

 mypath - Command line Tool  for easy changing PATH on Windows (Perl)

Dieses Tool ist als Project auf github abgelegt. Eine Suche auf github findet es: "mypath perl" . Der direkte Link bei Klick auf diese Worte mypath changing path windows perl  Wie oft bei solch kleinen Projekten lag der Schwerpunkt auf Funktionalität und nicht auf Schönheit. 

Der Hauptgedanke dahinter war, bei kurzfristigen Änderungen des PATH nicht immer den Schritt über 

Systemsteuerung >> System >> Erweiterte Systemeinstellungen (Systemeigenschaften) >> Umgebungsvariablen

 gehen zu müssen. Zudem ist der Zugang auf die Erweiterten Einstellungen oft an die Rechte eines local Admin gebunden.

Die Vorbedingungen sind:

• ein installiertes Perl und der Pfad der ausführbaren Datei (perl.exe) im PATH,
• alle notwendigen Dateien befinden sich in D:\temp , sonst Programmierung ändern,
• das Verzeichnis D:\temp befindet sich bereits in der PATH-Variable im Environment

Die Benutzung 

bietet zwei verschiedene Aufrufe:

Die Bearbeitung:

perl mypath.pl [-q] {delete|unshift|push} (dir1) [{delete|unshift|push} (dir2) ..]

Damit können Verzeichnisse gelöscht, am Anfang oder am Ende zum PATH hinzugefügt werden. Bei Verzeichnissen mit Leerzeichen müssen diese in Anführungszeichen (double quote) eingeschlossen werden. Da der PATH durch Perl unter Windows nicht an die übergeordnete Instanz der Kommandozeile durchgereicht werden kann, muss anschließend die Batch-Datei mypathnew.bat ausgeführt werden, die auch im Verzeichnis D:\temp liegt.

Die Auflistung:

perl mypath.pl list [-all|(dir-fragment)]

Damit können alle oder ausgewählte Verzeichnisse der Path-Variable aufgelistet werden. Der Parameter -all ist dabei optional. Für die Suche nach bestimmten Verzeichnissen genügt ein Bruchstück des Verzeichnisnamens.

Es existiert ein Schalter -q für stille (quiet) Verarbeitung. Dabei werden ein paar Ausgaben während der Verarbeitung unterdrückt. Zu diesem Schalter gibt es eine Alternative, man setzt die Environment Variable: 

MYPATH_QUIET=[Ja|Yes|true|1|-q|On]

Beim Auflisten (zweite Form der Benutzung) hat dieser Schalter keine Wirkung.

Another EditPad Pro thing - Regex in Python to find matches in csv rows

In A forum related to EditPad Pro a guy did ask for help with a Python issue he had. He told that he better wanted to do a Regexp-search instead of a fields search. But in real he accepted a fields search solution. So why he did ask for a Regexp solution? If he wanted to get a RE solution he first should read the CSV not as fields of records but simply as lines.

On the other hand he is mixing RE quantifiers. Once he writes {0,6} which means zero or more times which he mixes up with the optional quantifier question mark "?". So eighter he could better write {1,6}? or simply omit the question mark (optional) quantifier and write {0,6} without "?". This would have cleared the situation and both bring the same result. You can check it with EditPad Pro.

The question and the answers in short: bit.ly/32vuVZu

Google Mail and blocked attachments

little helper Perl-script

Subject:
Since Oct 24. 2017 I noticed changes in GMail behaviour on attachments.

What was the starting point?

Some years ago I had the requirement to send me or a colleague some
files. These files did include executables, which is impossible as
GMail attachment. Gmail blocks this for security reasons. I know that
there are other ways like Dropbox or other Cloud services. But in this
case e-mail was prefered for some reasons.

I'm working on Windows OS. So there may be better solutions under
Linux systems. The goal was to set up a script for comfortable
handling these mail attachments which means simple encrypting and
decrypting for sending in GMail. Also it should self set some
preferences as the destination filename in encrypting. And it should
recognize if it was an already encoded file on it's file-extension
(.b64). Besides this it further should cover and change known
file-extensions such as *.zip, *.bat, *.cmd, *.exe in replacing last
character with "_" (*.zi_ and so on). This did work fine with simple
base64 encrypting till the Oct 24 2017. The base64 encoded files could
be attached without any issues on a GMail e-mail.

What did happen? / What is the solution?

On the named date it did not work any longer. It seems Google did
recognize base64 encoded files. I thought on a simple solution to keep
the process running. The idea was that Google should not _see_ that it
was base64 .. and look into if there are zip's or executables. I
simply added a following ROT13 character shift in encoding. The
file-ext for encoding was set to *.b64.r13 .

The script runs with a Perl installation. On missing destination file
name it automatically sets an file-ext for destination. It recognizes
an already encrypted file on it's extension *.b64.r13 and does a
decode in this case. The base64 and ROT13-encoded files can be
attached without any difficulty to a GMail e-mail. The call on an
encrypted file does the reverse. The call of the Perl-script is done
with a batch-file wich should be able to found through PATH-variable.
An possibly overwrite is recognized and can be avoided.

The help message states:

baserot.pl - Benutzung/Usage: 

[perl] baserot.pl [-e|-d] [-o] (quelldatei/source) [(zieldatei/destination)]

-e       encode (default)
-d       decode
-o       overwrite existing
-h|help  diese Hilfe/this help
ext(encode) = .b64.r13 (if no dest set)
source ext .b64.r13 = action: decode

Project is on Github: https://github.com/toohoo/base64rot13