filetool.sh TC 10.1 trivial display bug: trailing slash in output

[webb]

Code: (bash) [Select]

webb@box ~ filetool.sh -b
Backing up files to /mnt/vda1/tce/mydata.tgz/
Done.caused by

Code: (bash) [Select]

echo -n on line 173 of filetool.sh combined with a following line outputting a slash, maybe

Code: (bash) [Select]

sudo /bin/tar -C /

[Rich]

Hi webb
The extra  /  character is coming from the  rotdash (rotating dash)  command. The  rotdash  command writes the following sequence:

Code: [Select]

/ Backspace
- Backspace
\ Backspace
| BackspaceSo depending on how long your backup takes, any one of those characters could be left behind. The attached patch file fixes it
by including a leading  space  character in the next 2  echo  commands. That will overwrite the character left by  rotdash.

    [EDIT]: Moved attachment to the next post.  Rich

[Rich]

Hi Juanito
The attached patch file does the following:
1. Adds a trailing space to the  "Backing up files to $MOUNTPOINT/$FULLPATH/${MYDATA}.tgz"  message so that  rotdash  does not
   print right next to the trailing  z. This also provides a space if the  "encrypting .. "  message gets printed which itself will overwrite
   anything that  rotdash  leaves behind.
2. Adds a leading space to the  "\nDone."  message to overwrite anything that  rotdash  leaves behind.

[Rich]

Hi Juanito
If there's any interest, I have a patch for  rotdash  that leaves the screen as it found it when it exits. Compiling under TC4 and
using  sstrip  increases the executables size from 1688 bytes to 1708 bytes. In TC10 I can't get the size under 12324 bytes.

The addition line of code is shown here with a comment and the diff is attached below:

Code: [Select]

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv){

if (argc != 2) return 1;

const char arr[] = { '/', '-', '\\', '|' };
unsigned int i = 0;
chdir("/proc");

while (access(argv[1],F_OK) == 0) {
printf("%c\b",arr[i]);
fflush(stdout);
i++;
i %= 4;
usleep(100000);
}

// This clears from the cursor to the end of the line leaving
// the screen and cursor as they were when the program started.
printf("\033[K");
return 0;
}
The source code I used came from here:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/3.x/rotdash.c

[Greg Erskine]

I often output rotdash into a <textarea> on a web page via filetool.sh. The backspace does not work now but it isn't a big problem.

If you add an escape character into the output it would be really bad for displaying via a web page.

I already have replacement rotdash code ready if it is decided you decide to procede.

Example:

Code: [Select]

[ INFO ] Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz/-\|/ Done.
[ OK ] Backup successful.

[curaga]

Let's go with the filetool patch, given Greg's web use.

[Juanito]

tinycore git updated

[Rich]

Hi Greg Erskine

I often output rotdash into a <textarea> on a web page via filetool.sh. The backspace does not work now but it isn't a big problem.

If you add an escape character into the output it would be really bad for displaying via a web page. ...

I had no idea anyone used this for a web page. I suppose I could have printed a  space  followed by a  backspace:

Code: [Select]

printf(" \b");Since the  backspace  moves the cursor back 1 position the trailing  space  would simply get overwritten if more text were added.
If the next character was a  newline,  it would print the trailing space which wouldn't be visible anyway. This was the mechanism
that made the trailing slash visible.

[jazzbiker]

Compiling under TC4 and using  sstrip  increases the executables size from 1688 bytes to 1708 bytes. In TC10 I can't get the size under 12324 bytes.

Hi, Rich!
Sorry for offtopic. Can you kindly explain to the newbie such a size difference?
Not a first mentioning of TC4 at the forum as the kind of milestone. What have changed later? Some kernel bloat?

[Rich]

Hi jazzbiker

... Can you kindly explain to the newbie such a size difference? ...

I honestly don't know why the executable is so much larger. My guess is the current compiler has some "enhancements" not present
in the TC4 version that add some overhead. There appear to be some differences in how they were built.

TC4:

Code: [Select]

tc@box:~/rotdash$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.1/configure --prefix=/usr/local --libexecdir=/usr/local/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --enable-frame-pointer
Thread model: posix
gcc version 4.6.1 (GCC)
tc@box:~/rotdash$
TC10:

Code: [Select]

tc@E310:~/rotdash$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/8.2.0/lto-wrapper
Target: i486-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++ --disable-multilib --disable-bootstrap --disable-libmpx --with-system-zlib --libexecdir=/usr/local/lib --enable-frame-pointer --with-mpfr=/usr/local --with-gmp=/usr/local
Thread model: posix
gcc version 8.2.0 (GCC)
tc@E310:~/rotdash$

[jazzbiker]

My guess is the current compiler has some "enhancements" not present
in the TC4 version that add some overhead.

Thanks for Your answer, Rich.
My feeling is that sometimes tcc is the real alternative to gcc - for simple programs.

[jazzbiker]

Continuing off-topic:

Code: [Select]

tc@box:/tmp$ uname -a
Linux box 4.19.10-tinycore #1999 SMP Tue Dec 18 13:36:47 UTC 2018 i686 GNU/Linux
tc@box:/tmp$ wget http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/3.
x/rotdash.c
Connecting to distro.ibiblio.org (152.19.134.43:80)
rotdash.c            100% |********************************|   317  0:00:00 ETA
tc@box:/tmp$ tce-load -i tcc
tcc is already installed!
tc@box:/tmp$ tcc -v
tcc version 0.9.26 (i386 Linux)
tc@box:/tmp$ tcc -o rotdash rotdash.c
tc@box:/tmp$ ls -l rotdash*
-rwxr-xr-x    1 tc       staff         2816 Aug 13 13:49 rotdash
-rw-r--r--    1 tc       staff          317 Aug 13 13:48 rotdash.c
tc@box:/tmp$ tce-load -i sstrip
sstrip is already installed!
tc@box:/tmp$ sstrip rotdash
tc@box:/tmp$ ls -l rotdash*
-rwxr-xr-x    1 tc       staff         1312 Aug 13 13:49 rotdash
-rw-r--r--    1 tc       staff          317 Aug 13 13:48 rotdash.c


[Rich]

Hi jazzbiker

I honestly don't know why the executable is so much larger. My guess is the current compiler has some "enhancements" not present
in the TC4 version that add some overhead. ...

I don't know why it's happening, but I know what's happening. I looked through the stripped file and found 3 large blocks of zeros.
Each block was over 3500 bytes long.

... In TC10 I can't get the size under 12324 bytes. ...

Subtracting 3 times 3500 from 12324 leaves 1824 which suggests all the growth consists of zero padding.

[jazzbiker]

I don't know why it's happening, but I know what's happening. I looked through the stripped file and found 3 large blocks of zeros.
Each block was over 3500 bytes long.

Some initialized variables. They may be examined better before stripping, probably.
But tcc gives 1312 total size )

[jazzbiker]

Code: [Select]

tc@box:/tmp/rotdash$ nm  -n -S rotdash
         U access@@GLIBC_2.0
         U chdir@@GLIBC_2.0
         U fflush@@GLIBC_2.0
         w __gmon_start__
         U __libc_start_main@@GLIBC_2.0
         U printf@@GLIBC_2.0
         U usleep@@GLIBC_2.0
08049000 T _init
08049090 T _start
080490c0 00000004 T __x86.get_pc_thunk.bx
080490c4 t deregister_tm_clones
080490ec t register_tm_clones
08049122 t __do_global_dtors_aux
08049140 t frame_dummy
08049142 000000bb T main
080491fd 0000004f T __libc_csu_init
0804924c 00000001 T __libc_csu_fini
08049250 T _fini
0804a000 00000004 R _fp_hw
0804a004 00000004 R _IO_stdin_used
0804a014 r __FRAME_END__
0804bf04 t __frame_dummy_init_array_entry
0804bf04 t __init_array_start
0804bf08 t __do_global_dtors_aux_fini_array_entry
0804bf08 t __init_array_end
0804bf0c d _DYNAMIC
0804c000 d _GLOBAL_OFFSET_TABLE_
0804c024 D __data_start
0804c024 W data_start
0804c028 D __dso_handle
0804c02c B __bss_start
0804c02c D _edata
0804c02c 00000004 B stdout@@GLIBC_2.0
0804c02c D __TMC_END__
0804c030 00000001 b completed.6835
0804c034 B _end
After _fini in text section next symbol is _fp_hw in read-only section and it is aligned on xxx000.
Then _GLOBAL_OFFSET_TABLE_ is aligned the same way.

There may be some linker switches concerning section alignment, i guess.

Th hole between __FRAME_END__ (read-only section) and __frame_dummy_init_array_entry (text section) is almost 8K.