Activity for Jörg Schilling
-
Jörg Schilling posted a comment on ticket #29
Make sure that you either give the full pathname to "truss" or have "p" in your PATH environment.
-
Truss is the name of the original program written by Roger Faulkner at AT&T around 1984. In 1987, SunOS-4.0 came out with a clone called trace. Around 1989, a person from the Sun User group wrote a trace clone called strace for SunOS-4 in order to find out how it works. It should be easy to find this information if you do not have the original program from Roger Faulkner. Truss is however available on most operating systems, so it seems to be the best to use that original command name.
-
author surname not displayed properly on linux terminal
-
Since revision schilytools 2021-09-01, all schilytools have been changed. If you install a translation file as mentioned in AN-2021-09-01, the problem is gone. This is currently already available in the FreeBSD binaries from the schilytoos.
-
Well, what you did is not a fix, since it only hides the problem for you instead of making the problem disappear for everyone. My solution works for everyone....
-
Hi, this is a rendering problem in your work environment. It seems that you are using an UTF-8 based locale and even though the low 256 characters from ISO-8859-1 and UNICODE are identical. you see rubbish. The next version of the schilytools come with a workaround. If you install a translation file, gettext() will call iconv() to convert the ’ö’ to what it is in your local setup. The announcement file for the next schilytools release will explain how to set up a translation file.
-
Star does not save empty linux extended attributes
-
fixed in schilytools-2021-07-29
-
Star does not save empty linux extended attributes
-
Sorry wrong file, here is the correct file.
-
This seems to be a corner case, since on Ubuntu 16.04, $ setfattr -n user.archived -v "" testfile is without effect, but does not give an error message. So I manually created a tar archive with a zeroed linux xattr. Please apply the attached patch to xheader.c and retry.
-
implicitly declaring library function 'exit'
-
Given that there is no new feedback since more than two weeks, I assume that the recent changes fixed the problem. Feel free to send a new but report if the problem still exists.
-
A new version of schilytools has been published. If there are no remaining problems, I will close this bug in a few days.
-
Hi, I just uploaded a new version of configure that adds some more #include statements in hope to find nearly all problems.
-
Hi, yesterday I had a discussion with a friend regarding return in main() and older C-compilers. We now believe that the main thing that was different in the 1980s as that the end of main() had a piece of special code that emulated a return 0, in case there was no return. So we now believe that it is possible to replace exit by return without destroying portability. There is a new "configure" script for testing in the schilytools download. Could you please test that and check foe remaining errors...
-
It seems that Apple is destroying the base of configure... The assumption is that a missing function prototype only results in a warning. First,I would need to do some research in order to verify what happens when using return in main() and whether this is usable at all with very old compilers...
-
Sorry, I copied the file to schillix by mistake. it is now where you expect it. Please try again.
-
OK, I copied the new configure file to the schilytools download area. I'll remove that file this evening in order to avoid confusion for other users.
-
Sorry for the delay, your report arrived at a time where I did not immediately reply and I then forgot about it. I believe a related fix would need in depth testing, since this is a behavior that differs from historic behavior. In special, checking for other possible occurrences of "error: implicitly" in config.log. Should I just include the changes in the next regular release or do you like to check the current state?
-
Typo in ved web page
-
Thank you for the hint. I fixed the typo.
-
A new version of schilytools with fixes for the jobcontrol handling is ready. Please test.
-
A new version of schilytools with fixed for the jobcontrol handling is ready. Please test.
-
Te first problem with exit code 0 istead of 12 is causd by two forgotten lines to keep the exit code from background jobs at another location that calls waitid(P_ALL...) This happened because you have been waiting for a foreground job while the background job terminated. The second is an endless loop caused by a joblist where the next pointer is not NULL but a pointer to itself. This may take some hours to investigate, why pointering is wring.
-
Please check the new schilytools version...
-
That are many questions... 1) SIGKILL cannot be cought, so the shell dies from that 2) SIGTERM is caught by the shell, so the shell does not die from it. With $/, you see a decimal number, indicating that the shell rather actively exited with 2000, indication an exception 3) I doubt that there is a reliable way to fetch the exit status from all background jobs. The shell from time to time waits for all children and thus reaps background jobs. Even ksh93 IIRC only remembers the exit status for up...
-
Well, thank you for asking. Triggered by your question, I discovered that $/ was destroyed in your special case resulting it to print 208 even on a real UNIX system unless you did previously call "set -o fullexitcode". That has been fixed. BTW: I plan to add a note for your problem to the "wait" part of the bosh manpage since the current text for $? is not easy to find/understand and incomplete with respect to 2000.
-
First an important note: you cannot expect a specific value in $? in your case, even if you did write a script that does what you intend. This is because POSIX does not require a specific value. ksh93 e.g. uses 256 + signo. Second, your script depends on undefined behavior, since you use the kill command before the sleep command has been started...so you send the signal to the forked shell. bosh is a really fast shell and for this reason, you are able to issue another command (like the builtin kill)...
-
bosh: export is not inherited
-
Problem when command substitution with redirection
-
The bug has been fixed in schily-2020-07-01
-
pbosh does not support OLDPWD
-
The problem has been fixed a while ago.
-
You are trying to use a POSIX feature where a hard deviation between POSIX and the classical Bourne Shell exists. Since the classical Bourne Shell behavior here gives more funtionality, bosh by default stays with the classical Bourne Shell export behavior as the default. There are two ways to get the beavior you like to see: call bosh -o posix call /opt/schily/xpg4/bin/sh instead of /opt/schily/bin/bosh The next release will install a symlink from /opt/schily/xpg4/bin/bosh to /opt/schily/xpg4/bin/sh...
-
You are trying to use a POSIX feature where a hard deviation between POSIX and the classical Bourne Shell exists. Since the classical Bourne Shell behavior here gives more funtionality, bosh by default stays with the classical Bourne Shell export behavior as the default. There are two ways to get the beavior you like to see: call bosh -o posix call /opt/schily/xpg4/bin/sh instead of /opt/schily/bin/bosh The next release will install a symlink from /opt/schily/xpg4/bin/bosh to /opt/schily/xpg4/bin/sh...
-
Hi, two days ago it did not work to add the attachment, now it has been added to the previous post.
-
Could you please check the attached patch? I am however not sure whether this is the final solution, as there is no binary node element for { ...;} grouping and other cases could also miss the {} when a back translation from a binary syntax tree into text happens. This back translation is used in the recursive parser for $()...
-
Could you please check the attached patch? I am however not sure whether this is the final solution, as there is no binary node element for { ...;} grouping and other cases could also miss the {} when a back translation from a binary syntax tree into text happens. This back translation is used in the recursive parser for $()...
-
Thank you for discovering this problem. I just made a bug report against POSIX: https://www.austingroupbugs.net/view.php?id=1343 Furthermore, I'll move that feature from cd extensions to POSIX cd.
-
libmdigest: add ARM endian detection when building with MSVC
-
Sorry for missing your report until now, so I'll could not include this in the release from today. It will be included in the next release in 2-4 weeks.
-
Parser confusion(?) with command substitution
-
Closed as it is fixed in the next release
-
bosh: Using set -e causes unexpected termination within the function
-
Closed as it is fixed in the next release
-
[bosh] Freeze when using pipe
-
Closed as it is fixed in the next release.
-
Parameter expansion is not compatible with other shells
-
OK, then this is closed.
-
Let me give an update: Both commands address completely different problems. The second command contains a space character and there was a plan to support this kind of problems 4 years ago. Background: the lexer normally sees two tokens and it needs to understand ${...} to include the unquoted space in a word. There should have been two changes in the lexer to support both ${...} and "${....}" but there was only one change for ${...}. The first command seems to have been defined in a strange way by...
-
Let me give an update: Both commands address completely different problems. The second command contains a space character and there was a plan to support this kind of problems 4 years ago. Background: the lexer normally sees two tokens and it needs to understand ${...} to include the unquoted space in a word. There should have been two changes in the lexer to support both ${...} and "${....}" but there was only one change for ${...}. The first command seems to have been defined in a strange way by...
-
Parameter expansion is not compatible with other shells
-
Ahh, I see that I forgot to use -u with "sccs diffs", but patch still should be able to deal with that output.
-
The first problem with the script was caused by a bug in the special code to allow read to run in the foreground shell. The tricks just should not be used for the child processes for the read conatining loop. The second example did not fail on Solaris and it seems that it also does no longer fail on Linux if the fix for the script has been applied. See attached patch.
-
The first problem with the script was caused by a bug in the special code to allow read to run in the foreground shell. The tricks just should not be used for the child processes for the read conatining loop. The second example did not fail on Solaris and it seems that it also does no longer fail with the fix for the script. See attached patch.
-
[bosh] Freeze when using pipe
-
It was not parser confusion, but missbehaved output optimization, please check the patch
-
OK, so it seems that the original cause for the problem had not been fixed. I have another patch to fix the orginal problem...
-
Hi, I am not sure whether the main issue is to never quit from inside a function if the return code of the function is checked. Could you check the attached patch?
-
I'll have a look at this. BTW: Do you have a larger test suite for these problem, or did you discover the problems ad hoc?
-
This is a really strange behavior that would need a longer investigation. It seems to be related to $(cmd) handling as it does not appen with cmd using backticks
-
This is a really strange behavior that would need a longer investigation. It seems to be related to $(cmd) handling as it does not appen with cmd
-
The second example seems to be correct in bosh, as it shows the same results as ksh88 that is the base for the POSIX shell. The fist example needs more checks.
-
The state of "set -e" is lost after "set --"
-
This problem is present in the january version but I cannot repeat it in the current version that was planned to be published yesterday. Please have a look for the new version today or tomorrow.
-
This problem is present in the january version but I cannot repeat it in the current version that was planned to be published yesterday. Please have a look for the new version today or tomorruw.
-
There is no freeze, but there is a problem with jobcontrol in the default new version of the shell that uses vfork. If you recompile bosh using: smake COPTX=-DNO_VFORK it does not have the mentioned job control problems. I would need to check this problem, but this may take some time...
-
sfind -depth -name combination seems broken
-
So closed as it has been fixed last year
-
There was only a minor problem, caused by not restoring the last component index after processing the directory content. Please check the attached patch...
-
It may be that I missed some dependency quirks... The directory is handled later in the function in case that -depth has been in use. I thought that this does not cause problems, so I did not test that :-(
-
Cannot listxattr for files in subdirectories
-
Fixed in schily-2019-07-15
-
sfind doesn't follow symlinks with -L and without -dostat
-
Fixed in schily-2019-09-22
-
sfind should check the root path's basename for -name
-
Fixed in schily-2019-09-22
-
This is expected to print OK. Since POSIX requires special handling for usage of shell variables, this case $x results in an empty string. Even the new bash5 prints OK with this example and bash5 has some problems with variable quiting caused by an ongoing diskussion in the POSIX team.
-
This is expected to print OK. Since POSIX requires special handling for usage of shell variables, this case $x results in an empty string. Even the new bash5 prints OK with this example and bash5 has some problems caused by an ongoing diskussion in the POSIX team.
-
If you like, you may try out this patch. It is not fully complete since there is a need to add support foe extra long path names (> 1024) but for most cases OK.
-
The fix takes a bit longer to fix as there are sevel small problems. Please use -find until the fix is ready.
-
Could you check whether this works if you use "-find ." instead of "."?schily There have been some code changes recently for performance reasons....
-
If you are on a UTF-8 based locale, try: > dash > $ IFS=ö > $ A=Jörg > $ echo $A > J rg > $ There are three arguments for echo (looks like two spaces between the visible words) the middle argument is empty. If you are in a UTF-8 terminal this works to compare: > dash -c 'IFS=ö; A=Jörg; echo $A' > J rg > bosh -c 'IFS=ö; A=Jörg; echo $A' > J rg Try this with any shell that could get a UNIX branding and you get only one space between J and rg. There are many more cases where it is important that the...
-
If you make sure that /usr/gnu/bin/is not in front of the PATH, it should work on OpenIndiana. There is a problem: sed was closed source as a collaborative delevopment with IBM and OpenIndiana does not have the Solaris sed but rather the FreeBSD sed that supports -E. So if you like to check for the possible problems on a certified POSIX issue 7 tc2 UNIX, you should try to fetch the free version of Oracle Solaris-11.4. SchilliX may be available in a newer variant late this year. Your claim with double...
-
The -E fix seems to work on the first view, but causes a "Terminated" message. I checked the whole with truss -f and it seems this is from a ffmpeg program /tmp/ffconf.XXl7aO2F/test whatever this is...it is not a bosh problem. Bosh just reports it in contrary to bash. BTW: neither ksh88 nor ksh93 work with that on Solaris: ksh configure --disable-x86asm configure[92]: test: argument expected configure[92]: test: argument expected configure[2]: 18227 Terminated ksh93 configure --disable-x86asm [1]...
-
The -E fix seems to work on the first view, but causes a "Terminated" message. I checked the whole with truss -f and it seems this is from a ffmpeg program /tmp/ffconf.XXl7aO2F/test whatever this is...it is not a bosh problem. Bosh just reports it in contrary to bash. BTW: neither ksh88 nor ksh93 work with that on Solaris: ksh configure --disable-x86asm configure[92]: test: argument expected configure[92]: test: argument expected configure[2]: 18227 Terminated ksh93 configure --disable-x86asm [1]...
-
I get two sed -E occurrences: /tmp/ffmpeg-4.1.3/configure:3721: sed -E -n "s/^extern AVFilter ff_([avfsinkrc]{2,5})_([a-zA-Z0-9_]+);/\2_filter/p" $file /tmp/ffmpeg-4.1.3/configure:5187: VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n /global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E "s/(.+[^*])$$$$/\1*/"' If you know a fix for that -E problem, I could test it on Solaris. Regarding your parameter expansion issue, I would need some time to investigate in that. I am...
-
The hint to quote ^ is recent, but it is just a bugfix to the POSIX standard. Thanks for the hint on finding a suitable shell. Sometimes it is a good idea to recheck things in a real window with more lines. I first checked the code at weekend on a laptop and did not see the check for /usr/xpg4/bin. So it seems that some time ago, the authors of ffmpeg did care about the standard and switched to the POSIX environment and my fear that grep -q could fail later is not correct. Now I would guess that...
-
Sorry, macro is the internal name in the Bourne Shell source, see macro.c POSIX calls it parameter expansion. Then also look at: http://austingroupbugs.net/view.php?id=1190 and http://austingroupbugs.net/view.php?id=1191#c4278 ksh is no problem on Solaris, the problem is that ffmpegs script is non-portable: ksh93 configure sed: illegal option -- E Usage: sed [-n] script [file...] sed [-n] [-e script]...[-f script_file]...[file...] ... and if you would remove that, it would complain about grep -q...
-
Sorry, macro is the internal name in the Bourne Shell source, see macro.c POSIX calls it parameter expansion. Then also look at: http://austingroupbugs.net/view.php?id=1190 ksh is no problem on Solaris, the problem is that ffmpegs script is non-portable: ksh93 configure sed: illegal option -- E Usage: sed [-n] script [file...] sed [-n] [-e script]...[-f script_file]...[file...] ... and if you would remove that, it would complain about grep -q because it does not set up a PATH to use the POSIX variants...
-
'^' was an alias for pipes in the 1970s to allow pipes on upper case only terminals. bosh still supports it as Solaris did come with /bin/sh being the classical Bourne Shell for a long time and as POSIX definitely does not make any assumptions on what shell /bin/sh is. It can be disabled in bosh via set -o posix and it is disabled by default in pbosh. We recently added '^' to the set of characters that need quoting in the POSIX standard because of some reported issues with globbing and pattern matching....
-
Well, ffmpeg does not use autoconf but a hand written shell script that it not "compliant" as it does not quote '^' (as required by the POSIX standard) and as it calls programs like sed with non-standard options. For this reason, it is not possible to check the ffmpeg script on an arbitrary certified UNIX and the script seems to be an example how scripts should not be written. Looking closer at the script, shows that this shell script causes the shell to spend most of the time in macro expansion,...
-
Well, ffmpeg does not use autoconf but a hand written shell script that it not "compliant" as it does not quote '^' (as required by the POSIX standard) and as it calls programs like sed with non-standard options. For this reason, it is not possible to check the ffmpeg script on an arbitrary certified UNIX and the script seems to be an example how scripts should not be written. Looking closer at the script, shows that this shell script causes the shell to spend most of the time in macro expansion,...
-
If you make dash POSIX compliant by adding multi byte character support, it would be the slowest shell ever. bosh is currently approx. 5% faster than dash even though it supports multi byte characters and 30% of the CPU time used by bosh is used for multi byte character handling. The original ksh93 is approx. 10% faster than bosh but the RedHat variant already has been made slower than the original by replacing code from David Korn with what the Redhat people believe is "standard code".
-
Hi, bosh produces the same output as you get from ksh88 that has been used as the reference implementation for POSIX and ksh88 based POSIX platforms like Solaris pass the POSIX certification tests with that behavior. Bourne Shell: sh -c 'v=foo eq== IFS==; echo A=A "$v"=\$bar' A A foo $bar ksh88 ksh -c 'v=foo eq== IFS==; echo A=A "$v"=\$bar' A=A foo $bar bosh: bosh -c 'v=foo eq== IFS==; echo A=A "$v"=\$bar' A=A foo $bar For your second example you get: Bourne Shell: [A][A][B][foo][$bar] ksh88: [A=A][B][][foo][$bar]...
-
[p]bosh: Parameter substitution: unable to trim arbitrary prefix/suffix
-
The new version is available for download
1 >
