From a Z/OS prompt, if I start bash, then use iconv to show an ASCII file, the whole bash shell becomes corrupted:
bash-4.3$ iconv -f 1047 -t 819 test.txt
The ascii/ebcdic gibberish is then echoed, ^d or exit does not terminate the shell.
This behavior does not happen with sh or tcsh. Note the same behavior happens with other code pages.
we know, that this usage of iconv breaks bash. However, in my opinion this command is meaningless. If you need to read a file, you should tag it with command:
chtag -tc 819 < file > #For ASCII file
chtag -tc 1047 < file > #For EBCDIC file
Then you can read it with command “cat < file >”.
If you want to change encoding of the file, you need to use redirection: iconv -f 1047 -t 819 test.txt > test1.txt
I do not agree that iconv is per se meaningless because of using bash although I agree that there are many situations where indeed chtag is the better choice.
Funny: when I run iconv in a shell I get a corrupted prompt but the bash is still usable. Means: I press ENTER and then the prompt is ok. And of course I can enter commands aso.
This is from last year.
One addition: When I type cksum command and then Ctrl-C then the bash is unusable. Nothing helps, I have to kill my ssh session from the outside.
If this is a bug in bash do you plan to fix it?
Thanks for reporting this. We’re going to review bash code in future and check what’s causing the issue.
Hi Vladimir, thanks for looking into this.
I should add that it is important for me to understand if this is a problem in the bash shell or not.
If it isn’t then I would pursue things (regarding cksum behavior) with IBM.
We suspect it might be a bash issue but we don’t know for sure at the moment. We need to research this first quite a bit.
Hi Vlad, thanks for the status.