Run like Hell

Feb 3, 2018

Ubuntu 17.10: s2disk/hibernate broken with kernel 4.13.0-32

Last week my notebook refused to startup after s2disk/hibernate. The resume process started up to 100% and then the screen went black and everything stopped...

Hmm...
First idea: Something disappeared inside the grub configuration.

But this was okay.

After nearly one hour my last try was booting an old kernel. And with

schroff@zerberus:/boot$ uname -a
Linux zerberus 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:04:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

s2disk and resume worked again...

Jan 27, 2018

Bash: How to trim/truncate variables / get substrings

In a comment to one of the most useless commands postings was shown how to use the rev command to get the last component of the path out of a log file:

cat log | grep pattern | rev | cut -d '/' -f 1 | rev

If you only have one variable filled with a path, you can get the last component very easy:

schroff@zerberus:~$ myvar=/ab/cd/ef/gh

schroff@zerberus:~$ echo ${myvar##*\/}
gh

?

## removes the longest matching string for the pattern "*\/" from the beginning (the slash has to be escaped with a backslash).

schroff@zerberus:~$ echo ${myvar#*\/}
ab/cd/ef/gh

# removes the shortest matching pattern. Here only the starting "/"

% and %% removes everything from the end up to the pattern:

schroff@zerberus:~$ echo ${myvar%\/*}
/ab/cd/ef
schroff@zerberus:~$ echo ${myvar%%\/*}

Here the content of the bash manpage:

       ${parameter#word}
       ${parameter##word}
Remove matching prefix pattern. The word is expanded to produce a pattern just
as in pathname expansion. If the pattern matches the beginning of the value of
parameter, then the result of the expansion is the expanded value of parameter
with the shortest matching pattern (the ``#'' case) or the longest matching
pattern (the ``##'' case) deleted. If parameter is @ or *, the pattern removal
operation is applied to each positional parameter in turn, and the expansion is
the resultant list. If parameter is an array variable subscripted with @ or *,
the pattern removal operation is applied to each member of the array in turn,
and the expansion is the resultant list.

       ${parameter%word}
       ${parameter%%word}
Remove matching suffix pattern. The word is expanded to produce a pattern just
as in pathname expansion. If the pattern matches a trailing portion of the
expanded value of parameter, then the result of the expansion is the expanded
value of parameter with the shortest matching pattern (the ``%'' case) or the
longest matching pattern (the ``%%'' case) deleted. If parameter is @ or *,
the pattern removal operation is applied to each positional parameter in turn,
and the expansion is the resultant list. If parameter is an array variable
subscripted with @ or *, the pattern removal operation is applied to each mem‐
ber of the array in turn, and the expansion is the resultant list.

Jan 25, 2018

Java 9: JDK without subfolder JRE

In older JDK releases the directory structure was:

bin
db
include
jre
lib

With JEP 220 the jre folder was removed.

A JDK image no longer contains a jre subdirectory, as noted above. Existing code that assumes the existence of that directory might not work correctly.

But this does not mean that there is no JRE any more. You can still download the JRE. There are some minor changes to the JRE like:

The bin directory in a JRE image contains a few commands that were previously found only in JDK images, namely appletviewer, idlj,jrunscript, and jstatd. As with the previous item, these changes are a consequence of the way in which components that contain both APIs and tools were modularized.

For both version the files rt.jar, tools.jar and dt.jar are removed:

JDK and JRE images no longer contain the files lib/rt.jar,lib/tools.jar, lib/dt.jar, and other internal JAR files, as noted above. Existing code that assumes the existence of these files might not work correctly.

But this should not be a problem:

Class and resource files previously found in lib/dt.jar and visible only when that file was added to the class path are now visible via the bootstrap class loader and present in both the JRE and the JDK.

Everyone who delivers Java applications should read JEP 220 and check, what has to be changed...