Double click a Windows batch file (*.bat, *.cmd) and keep the command prompt open

Abstract

This is a quick tip about Windows batch files (.bat, .cmd). I often use these files to setup different development environments; setting environment variables, update %PATH%, different %JAVA_HOME%, etc. Sometimes it can be a challenge to do this, not lose these settings, and keep the command prompt (DOS window) open all at the same time. This is a technique I found which seems to do all this reliably.

Disclaimer

This post is solely informative. Critically think before using any information presented. Learn from it but ultimately make your own decisions at your own risk.

Example

This is an example run.cmd file. The basic idea is when you double-click this file, the script will actually call itself again which you can see in the :cmd section. After the script calls itself again, the :run section is where you put the details of your script.

Listing 1 - run.cmd

@echo off

REM Check the value of the 1st command line argument.
REM If the value is empty, go to the 'cmd' section
IF "%~1" == ""    GOTO cmd

REM Check the value of the 1st command line argument.
REM If the value is "run", go to the 'run' section
IF "%~1" == "run" GOTO run

REM If the 1st command line argument is not empty,
REM but not the value "run" then just 'end' because
REM this script doesn't know how to handle it.
ECHO Command line argument "%1" is not understood.
GOTO end

:cmd
REM In this section, use the %0 value in order to 
REM have this script call itself again.  By calling
REM itself with `cmd /K` you get a command prompt 
REM (DOS window) which won't automatically close
REM when this script is finished executing.
ECHO In the 'cmd' section
ECHO Script file=%0
cmd /K "%0 run"
GOTO end

:run
REM In this section, this is where you want to put
REM the work of your script.  You can execute whatever
REM you need and even call other scripts.  The
REM command prompt window will remain open because
REM of what the 'cmd' section does.
ECHO In the 'run' section

SET SOME_PROPERTY=foo
ECHO SOME_PROPERTY=%SOME_PROPERTY%

ECHO call env.cmd
call "%~dp0\env.cmd"

ECHO ENV_PROPERTY_1=%ENV_PROPERTY_1%
ECHO ENV_PROPERTY_2=%ENV_PROPERTY_2%
ECHO ENV_PROPERTY_3=%ENV_PROPERTY_3%

:end

Summary

That’s it. Really easy. Enjoy!

My JavaOne Session (2017)

Materials

GitHub (thoth-jaspic): JASPIC Research EE 6+

GitHub (thoth-security-api): Security API Research EE 8+

PowerPoint: Modern Application and Microservices Security from EE6 JASPIC to the EE8 Security API

Session

Session ID: CON5954

Session Title: Modern Application and Microservices Security from EE6 JASPIC to the EE8 Security API

Room: Moscone West - Room 2024

DATE: Tuesday, 10/03/17

Time: 09:30:00 AM

Proposal

Abstract

EE6 added the Java Authentication Service Provider Interface for Containers (JASPIC) to the EE specification. JASPIC is a flexible and customizable way for EE servers and applications to generate a Principal and roles for securing application. Unfortunately, JASPIC has been a specification few knew about. But with EE8, microservices, and focus on the new EE Security API, JASPIC is starting to get attention. This session will look at JASPIC and the EE Security API from a modern application & microservices security perspective. This session will first demonstrate how to secure the major EE components (Servlet, JSP, JSF, JAX-RS, JAX-WS) with JASPIC. Then it will demonstrate how security will change migrating to EE 8 and the EE Security API.

Summary

EE6 added the Java Authentication Service Provider Interface for Containers (JASPIC) to the EE specification. JASPIC is a flexible and customizable way for EE servers and applications to generate a Principal and roles for securing application. Unfortunately, JASPIC has been a specification few knew about. But with EE8, microservices, and focus on the new EE Security API, JASPIC is starting to get attention. This session will look at JASPIC and the EE Security API from a modern application & microservices security perspective. This session will first demonstrate how to secure the major EE components (Servlet, JSP, JSF, JAX-RS, JAX-WS) with JASPIC. Then it will demonstrate how security will change migrating to EE 8 and the EE Security API.

The EE security model has been one the biggest obstacles I’ve faced convincing organizations to stop using 3rd party proprietary frameworks. The assumption is that EE security is limited to BASIC, FORM, DIGEST and these do not fit the complex needs applications have when it comes to authentication and authorization. Specifically in modern application architecture, where there is typically a single-sign on, identity management layer protecting all applications within an organization, the Java EE standard is seen as unable to integrate with this layer so a 3rd party proprietary framework is needed to fill in the gaps with Java EE. But, since EE 6, Java has had the JASPIC specification. JASPIC already “fills this gap” within an EE standard, but hardly anyone knows about it. It wasn’t until EE 8 and the new EE Security API that I learned about JASPIC. Now JASPIC is low-level and a bit difficult to use, but the EE Security API will be built on top of JASPIC, so it’s a specification development teams need to know about. Both of these standards need to be evangelized and good example applications need to be made available which show how they are used to secure all the major EE components (Servlet, JSP, JSF, JAX-RS, JAX-WS, etc.). If developers know robust security exists with the EE specification and have examples showing how to secure the code they are developing, I believe more teams will stick with the standard vs 3rd party proprietary frameworks.

Pictures

billboard

room