Tiny Core Linux
Off-Topic => SCM EXtensions => Archive / Obsolete => SCM Extension Requests => Topic started by: SamK on June 01, 2012, 02:42:51 AM
-
This has stood the test of time well and remains very useful. I find the "User Menu" function particularly helpful to script and execute my repetive tasks.
-
I will aim to package it in the next day or so.
-
Built and packaged from source, tested out ok here, and uploaded.
-
Fixed typo that prevents browsing tar files, uploading again.
-
...uploading again.
Thanks for this, initial tests look good.
One issue to report at present. The info file indicates "bzip2 - 1.0.6" is included. When attempting to compress a file the mc console reports:
bzip2: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
Producing and extracting .gz and tar.gz files works OK.
-
Ok, I will look into it tonight. I never really used MC, preferring either the command line or a graphical app like rox or emelfm2, so my testing of it was limited.
I am away from TC today, but my hunch is that I may need to create a wrapper for the bzip2 binaries in /apps/mc/localbin, or preferably to just re build bzip2 as static to keep it simpler without needing a wrapper for every one of it's invocations.
-
This has stood the test of time well and remains very useful. I find the "User Menu" function particularly helpful to script and execute my repetive tasks.
Can you script in mc? Is it something similar to what vim/emacs is capable of?
-
Can you script in mc?
The included user manual has guidance on its scripting capabilities which is quite helpful. Examples of the structure can be found in ~/.mc/menu. There are also many sites with helpful information.
-
Should be working now, with static bzip2.
-
Should be working now, with static bzip2.
Confirming it now works as expected. Thanks.
I will now request a series of scm command line apps I regularly use via the MC User Menu facility.
-
i might be wrong but seems mc.scm should include
grep, gawk and isoinfo to view iso-images content
lynx to view html-files and groff to view man-files
-
i might be wrong but seems mc.scm should include
grep, gawk and isoinfo to view iso-images content
lynx to view html-files and groff to view man-files
A quick scan of the files and dependencies for the tcz version show they are not included for that format either. This raises a question, probably one of many that may occur as the scm format matures.
Where an app exists in both tcz and scm types should they both offer ther same range of capabilities?
In my view, the two formats are aimed at different goals and have different download sizes. It seems appropriate that they might also offer different capabilities, contain different versions and be updated at different frequencies (scm less often than tcz).
-
i think it was too quick scan :)
you can try to look at iso, html or man by using mc
and then see which messages shows up in mc
or do the following
$ egrep -rw '(gawk|grep|isoinfo)' /apps/mc/libexec/mc/extfs.d
/apps/mc/libexec/mc/extfs.d/README:that mc can use. Currently awk (or gawk) is used because nearly all systems
/apps/mc/libexec/mc/extfs.d/audio: cdparanoia -Q -d "$1" 2>&1 | grep '^[ 0-9][ 0-9][ 0-9]\.' | while read A B C
/apps/mc/libexec/mc/extfs.d/audio: RESPONSE=`wget -q -T $CDDB_TIMEOUT -O - "$CDDB_SERVER/~cddb/cddb.cgi?cmd=cddb+query+$DISCID&$CDDB_HANDSHAKE" | tee "$3" | gawk '/^200/ { print $2,$3; }'`
/apps/mc/libexec/mc/extfs.d/audio: wget -q -T $CDDB_TIMEOUT -O - "$CDDB_SERVER/~cddb/cddb.cgi?cmd=cddb+read+$RESPONSE&$CDDB_HANDSHAKE" | grep -v "^#" >> "$3"
/apps/mc/libexec/mc/extfs.d/deba: chop($debd = `dpkg -s $qarchive | grep -i ^Version | sed 's/^version: //i'`);
/apps/mc/libexec/mc/extfs.d/deba: chop($deba = `apt-cache show $qarchive | grep -i ^Version | sed 's/^version: //i'`);
/apps/mc/libexec/mc/extfs.d/debd: chop($status = `dpkg -s $qarchive | grep ^Status`);
/apps/mc/libexec/mc/extfs.d/dpkg+: system("if dpkg -s $qname | grep ^Status | grep -qs config-files; \
/apps/mc/libexec/mc/extfs.d/hp48+:AWK=gawk
/apps/mc/libexec/mc/extfs.d/iso9660:# tested to comply with isoinfo 2.0's output
/apps/mc/libexec/mc/extfs.d/iso9660: CHARSET=`locale 2>/dev/null | /usr/local/bin/grep LC_CTYPE | sed -n -e 's/.*\.\(.*\)"$/\1/p'`
/apps/mc/libexec/mc/extfs.d/iso9660: isoinfo -j $CHARSET -i /dev/null 2>&1 | /usr/local/bin/grep "Iconv not yet supported\|Unknown charset" >/dev/null && CHARSET=
/apps/mc/libexec/mc/extfs.d/iso9660: ISOINFO="isoinfo -R"
/apps/mc/libexec/mc/extfs.d/iso9660: ISOINFO_D_I="`isoinfo -d -i "$1" 2>/dev/null`"
/apps/mc/libexec/mc/extfs.d/iso9660: echo "$ISOINFO_D_I" | /usr/local/bin/grep "UCS level 1\|NO Joliet" > /dev/null || ISOINFO="$ISOINFO $JOLIET_OPT"
/apps/mc/libexec/mc/extfs.d/iso9660: if [ `echo "$ISOINFO_D_I" | /usr/local/bin/grep "Joliet with UCS level 3 found" | wc -l` = 1 \
/apps/mc/libexec/mc/extfs.d/iso9660: -a `echo "$ISOINFO_D_I" | /usr/local/bin/grep "NO Rock Ridge" | wc -l` = 1 ] ; then
/apps/mc/libexec/mc/extfs.d/iso9660:$ISOINFO -l -i "$1" 2>/dev/null | gawk -v SEMICOLON=$SEMICOLON '
/apps/mc/libexec/mc/extfs.d/lslR:AWK=gawk
/apps/mc/libexec/mc/extfs.d/rpm: if test "`echo supportedTags | grep -c CONFLICTS`" -eq 1; then
/apps/mc/libexec/mc/extfs.d/trpm: $RPM -q --qf "[%{REQUIRENAME}\n]" -- "$1" | grep "(none)" > /dev/null ||
/apps/mc/libexec/mc/extfs.d/trpm: $RPM -q --qf "[%{OBSOLETES}\n]" -- "$1" | grep "(none)" > /dev/null ||
/apps/mc/libexec/mc/extfs.d/trpm: $RPM -q --qf "[%{PROVIDES}\n]" -- "$1" | grep "(none)" > /dev/null ||
/apps/mc/libexec/mc/extfs.d/trpm: $RPM -q --qf "[%{CONFLICTS}\n]" -- "$1" | grep "(none)" > /dev/null ||
/apps/mc/libexec/mc/extfs.d/trpm: $RPM -qlv -- "$1" | grep '^[A-Za-z0-9-]'
/apps/mc/libexec/mc/extfs.d/u7z: $P7ZIP l "$1" "$2" | grep -q "0 files, 0 folders" && \
/apps/mc/libexec/mc/extfs.d/u7z: $P7ZIP l "$1" "$2" | grep -q "0 files, 0 folders" && \
/apps/mc/libexec/mc/extfs.d/u7z: $P7ZIP d "$1" "$EXFNAME" 2>&1 | grep -q E_NOTIMPL > /dev/null 2>&1 && \
/apps/mc/libexec/mc/extfs.d/u7z: $P7ZIP l "$1" "$2" | grep -q "0 files, 0 folders" && \
/apps/mc/libexec/mc/extfs.d/u7z: $P7ZIP d "$1" "$EXFNAME"/ 2>&1 | grep -q E_NOTIMPL > /dev/null 2>&1 && \
/apps/mc/libexec/mc/extfs.d/uace: $ACE_LIST "$1" | gawk -v uid=$UID '
/apps/mc/libexec/mc/extfs.d/ualz: $UNALZ -l "$1" | gawk -v uid=`id -nu` -v gid=`id -ng` '
/apps/mc/libexec/mc/extfs.d/uarc: $ARC_LIST "$1" | gawk -v uid=$UID '
/apps/mc/libexec/mc/extfs.d/uarj: $ARJ v "$1" | gawk -v uuid=$(id -ru) '
/apps/mc/libexec/mc/extfs.d/uc1541: $C1541 "$1" -list | gawk -v uid=$UID '
/apps/mc/libexec/mc/extfs.d/ucab: $CAB -l "$1" | gawk -v uid=`id -un` -v gid=`id -gn` '
/apps/mc/libexec/mc/extfs.d/uha: $HA lf "$1" 2>/dev/null | gawk -v uid=$(id -ru) '
/apps/mc/libexec/mc/extfs.d/ulha:# Tested with mc 3.5.18 and gawk 3.0.0 on Linux 2.0.0
/apps/mc/libexec/mc/extfs.d/ulha:AWK=gawk
/apps/mc/libexec/mc/extfs.d/urar: $UNRAR v -c- -cfg- "$1" | gawk -v uid=`id -u` -v gid=`id -g` '
/apps/mc/libexec/mc/extfs.d/uzoo: $ZOO lq "$ARCHIVE" | gawk -v uid=$(id -ru) '$ egrep -rw '(lynx|groff)' /apps/mc/etcfiles/mc
/apps/mc/etcfiles/mc/mc.ext: Open=(if test -n "" && test -n "$DISPLAY"; then ( file://%d/%p &) 1>&2; else links %f || lynx -force_html %f || ${PAGER:-more} %f; fi) 2>/dev/null
/apps/mc/etcfiles/mc/mc.ext: View=%view{ascii} links -dump %f 2>/dev/null || w3m -dump %f 2>/dev/null || lynx -dump -force_html %f
/apps/mc/etcfiles/mc/sfs.ini:uhtml/1 lynx -force_html -dump %1 > %3
/apps/mc/etcfiles/mc/sfs.ini:uman/1 groff -Tascii -man %1 > %3
/apps/mc/etcfiles/mc/sfs.ini:url:2 lynx -source `echo "%2" | sed 's-|-/-g'` > %3
-
i think it was too quick scan :)...
It seems that we are communicating at crossed purposes. I was referring to the information in the repo rather than a local installation. In TC the info as displayed in Apps-->Cloud-->Browse-->mc under the "Files" and "Depends" tabs.
-
yes i understood
but what do you think about the possibility to view iso, html and man by using mc?
yet it would be nice if it were possible to look 7z, rar and zip archives
ie p7zip.tcz, unrar.tcz and zip-unzip.tcz should be also included
however based on my experience is not enough to include zip-unzip.tcz to view zip
need something else which i still have not been able to determine...
proceeding from the fact that tinycore does not provide these tools by default
and self-contained module contain instruments for disclosing its capabilities
then it seems that the above-mentioned tools must be included to mc.scm
-
I agree in general that scms should be as full featured as practical. In time I will add the other compression tools. But at the same time, I think we should allow leaving some things optional that are solved by simply installing a tcz to provide extra functionality, similar to how the tczs do. One example would be optionally installing python to provide python support that is not critical for the app, as opposed to including python in the scm when it is not necessary.
-
...it would be nice if it were possible to look 7z, rar and zip archives
ie p7zip.tcz, unrar.tcz and zip-unzip.tcz should be also included
however based on my experience is not enough to include zip-unzip.tcz to view zip
need something else which i still have not been able to determine...
If I understand you correctly, you would like to look inside each archive file to view the files and directories it contains. This is already possible.
Have a look earlier in the topic at reply #9. I posted the following requests for p7zip, Unrar, and Zip-Unzip in scm format.
- http://forum.tinycorelinux.net/index.php/topic,13430.0.html
- http://forum.tinycorelinux.net/index.php/topic,13431.0.html
- http://forum.tinycorelinux.net/index.php/topic,13431.0.html
They have already been added to the repo.
Using these in combination with the "User Menu" facility included within Midnight Commander it is possible to list the contents, check the integrity, and of course extract from and create an archive in the various different formats.
...but what do you think about the possibility to view iso, html and man by using mc?
I have not used mc for viewing these types of files, but can see they might be useful to others.
I did, however take a quick look at html and it seems that mc expects lynx is installed. I also quickly looked at ISO viewing and again mc expects to use isoinfo. I didn't look at viewing man pages.
In general terms I favour full featured scms, and can see the case for the inclusion of such programs where the "parent" scm has such fixed expectations. The archivers I see slightly differently. These tend to be optional rather than fixed, and therefore the case for inclusion is not as strong.
Edit:
I forgot to mention, installing lynx.tcz did enable viewing of an html file via mc.scm. You might consider the value of adding requests for lynx and isoinfo to be produced as scms until they are integrated within mc, or install the tcz version.
-
I agree with Sam's observation about expected web browsers that apps want to use to view man or web pages. Filezilla, if I recall, uses firefox when you click it's help menu. And it would be ridiculous to include a firefox install within the filezilla.scm extension. Optionally installing firefox is much more sane.
Several apps use firefox to display help pages, and of course it is left as an option to install a firefox extension.
-
...it would be nice if it were possible to look 7z, rar and zip archives
ie p7zip.tcz, unrar.tcz and zip-unzip.tcz should be also included
however based on my experience is not enough to include zip-unzip.tcz to view zip
need something else which i still have not been able to determine...
If I understand you correctly, you would like to look inside each archive file to view the files and directories it contains. This is already possible.
Have a look earlier in the topic at reply #9. I posted the following requests for p7zip, Unrar, and Zip-Unzip in scm format.
- http://forum.tinycorelinux.net/index.php/topic,13430.0.html
- http://forum.tinycorelinux.net/index.php/topic,13431.0.html
- http://forum.tinycorelinux.net/index.php/topic,13431.0.html
They have already been added to the repo.
yes it is right, i still have installed these tcz extensions
but what meaning to change them to scm analogues?
this is the same as to bargain one trouble for another
yes i agree about the inclusion of web browsers
furthermore in the repo exists links2 that interchangeable with lynx for use in the mc
however think that not entirely correct to compare firefox (or python) with lynx
considering overhead ie its size and its demand for autonomous use
but about archivers and tools such as gawk, grep, groff and isoinfo let me to disagree
maybe enough to create coreutils.scm and cdrtools.scm and subject will be not actual
but you must agree that nobody have objections to inclusion archivers to xarchiver
although if i not mistaken most of them also don't depend strongly and can be used optionally
mc is a same handy tool for extraction from archives or iso-images and using as viewer
and think that i'm not lonely by using it that way
considering their low overall overhead (compared to python etc)
it seems to me that their inclusion has a more sense and a significant advantage
over the creating and installing of these small modules separately
of course i may be wrong about this matter
but i will try different options
-
I will consider including those non web browser apps like groff, isoinfo, and such into mc.scm, since not needing dependencies is part of the concept.
-
yes it is right, i still have installed these tcz extensions
but what meaning to change them to scm analogues?
this is the same as to bargain one trouble for another
For me, the primary benefit of the scm format is it's resistance to breakage due to changes in dependencies. The pace of development within TC is very rapid. There are a limited number of preventative measures a user might take to protect against breakages introduced at the OS level. The adoption of the scm format will increase the reliability at the application level. For me this benefit alone outweighs the larger size of an scm v equivalent tcz.
Archivers are widely used programs, both standalone and within larger applications. It would be disappointing if they were only available as part of a "parent" application or as a tcz.
but you must agree that nobody have objections to inclusion archivers to xarchiver
although if i not mistaken most of them also don't depend strongly and can be used optionally
mc is a same handy tool for extraction from archives...
This is not really a like-for-like comparison. The case for including archiving programs within an archiviving application is more compelling than for their inclusion within a general purpose file manager. Xarchiver would not be able to fulfill its purpose without them, however it is the use of them that is optional rather than whether or not they are included. Within mc it is the inclusion of them that is optional as they are not fixed requirements.
yes i agree about the inclusion of web browsers
furthermore in the repo exists links2 that interchangeable with lynx for use in the mc
however think that not entirely correct to compare firefox (or python) with lynx
considering overhead ie its size and its demand for autonomous use
I tend to have multiple browsers installed, among them links2 which I use as a standalone app. It is indeed automatically used by mc in place lynx, thanks for the tip. Again, I would not want to have it become available only as part of mc. I can see your point that lynx is small enough to be included within mc and have some sympathy with this view.
It is possible that including it might raise a precendent and used to request the inclusion of other large apps within other "parent" scms in the way previously described by JasonW. After all, what is small (or large) to you or me may not be so for everyone.
I am curious about the request to include grep. I have not made any specific tests but as it is included as a default part of the OS is it not usable by mc, or does the OS default program not supply a feature you (or mc) requires?
-
Archivers are widely used programs, both standalone and within larger applications. It would be disappointing if they were only available as part of a "parent" application or as a tcz.
yes, exclusively this i meant
For me, the primary benefit of the scm format is it's resistance to breakage due to changes in dependencies. The pace of development within TC is very rapid. There are a limited number of preventative measures a user might take to protect against breakages introduced at the OS level. The adoption of the scm format will increase the reliability at the application level. For me this benefit alone outweighs the larger size of an scm v equivalent tcz.
i want to note that there is one more advantage scm over tcz
despite for occupied larger but scm use less system power when loaded than tcz
this is especially noticeable on slower computers
yes i agree about the inclusion of web browsers
furthermore in the repo exists links2 that interchangeable with lynx for use in the mc
however think that not entirely correct to compare firefox (or python) with lynx
considering overhead ie its size and its demand for autonomous use
I tend to have multiple browsers installed, among them links2 which I use as a standalone app. It is indeed automatically used by mc in place lynx, thanks for the tip. Again, I would not want to have it become available only as part of mc. I can see your point that lynx is small enough to be included within mc and have some sympathy with this view.
no, i meant that i agree that should not include browsers specifically in this case
I am curious about the request to include grep. I have not made any specific tests but as it is included as a default part of the OS is it not usable by mc, or does the OS default program not supply a feature you (or mc) requires?
unfortunately having busybox grep but mc somehow does not want to use them and gives an error
i don't know why this occurs, may need to change mc config files settings...
incidentally using the occasion i would ask about one thing
using mc.tcz under desktop i could to use ctrl+enter to place selected item to the command line
for some reason mc.scm does not do this that very uncomfortable because is often used
through that this could occur and is it possible to fix it?
beforehand thanks for help
-
incidentally using the occasion i would ask about one thing
using mc.tcz under desktop i could to use ctrl+enter to place selected item to the command line
for some reason mc.scm does not do this that very uncomfortable because is often used
through that this could occur and is it possible to fix it?
beforehand thanks for help
Nothing to do with mc.tcz it is up to your terminal/WM. For example it works just fine in Xfce.
-
i wanted say that before uninstalled mc.tcz
key binding ctrl+enter worked properly
with jwm[-snapshot] and lxdm
after mc.scm was installed
then ctrl+enter stopped working
no additional settings do not made
also no special key bindings settings
all settings was installed by default
p.s.
would only note additionally
that this stopped working only when mc runs under wm
when switch to ctrl+alt+f1 then ctrl+enter is working in mc
-
This is the beauty of the flexible and modular system :)
-
and what to do? :D
-
For me, the primary benefit of the scm format is it's resistance to breakage due to changes in dependencies. The pace of development within TC is very rapid. There are a limited number of preventative measures a user might take to protect against breakages introduced at the OS level. The adoption of the scm format will increase the reliability at the application level. For me this benefit alone outweighs the larger size of an scm v equivalent tcz.
i want to note that there is one more advantage scm over tcz
despite for occupied larger but scm use less system power when loaded than tcz
this is especially noticeable on slower computers
I made my comment as a direct response to what I understood to be your question asking why I had requested the archivers as independent SCMs rather than including them within mc.scm. I agree there are multiple attractions to the format but discussion of them may be better suited to a different topic.
I am curious about the request to include grep. I have not made any specific tests but as it is included as a default part of the OS is it not usable by mc, or does the OS default program not supply a feature you (or mc) requires?
unfortunately having busybox grep but mc somehow does not want to use them and gives an error
i don't know why this occurs, may need to change mc config files settings...
Within mc.scm the busybox grep seems to work in the following test:
In the directory /home/tc
ls -1a | grep ash
.ash_history
.ashrc
.bashrc
Note you may need key-combination CTL+o to view the result
-
i do not say that busybox grep does not work on the command line
i only claim that the mc does not want to use him in their operations
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=13382.0;attach=3469)
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=13382.0;attach=3470)
ie mc for some reason requires gnu grep
For me, the primary benefit of the scm format is it's resistance to breakage due to changes in dependencies. The pace of development within TC is very rapid. There are a limited number of preventative measures a user might take to protect against breakages introduced at the OS level. The adoption of the scm format will increase the reliability at the application level. For me this benefit alone outweighs the larger size of an scm v equivalent tcz.
i want to note that there is one more advantage scm over tcz
despite for occupied larger but scm use less system power when loaded than tcz
this is especially noticeable on slower computers
I made my comment as a direct response to what I understood to be your question asking why I had requested the archivers as independent SCMs rather than including them within mc.scm. I agree there are multiple attractions to the format but discussion of them may be better suited to a different topic.
yes, i agree that it is slightly went beyond the current subject
but nevertheless this is helpful information, thanks :)
-
Hi AbNoRMiS
That message only suggests that grep can't be found, not that busybox grep won't work.
-
this is true but i have not tested whether mc can use busybox grep
for determination of this needs to change configuration files for mc
-
Hi AbNoRMiS
Actually, all you need to do is add a /bin/grep link to /usr/local/bin/grep to see if ti works.
-
yes it can be done :) but even if this will work
then in the mc this would not work immediately
"taking from box" without additional changes
-
Hi AbNoRMiS
That is only to determine if it works. If it does, the fix would be to change the hard coded path in /apps/mc/...../iso9660
(and any other scripts) from /usr/local/bin/grep to grep.
-
now i launched sudo ln -s /bin/grep /usr/local/bin && tce-load -i gawk.tcz
but then mc does not issue any errors and don't shows contents of iso-images
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=13382.0;attach=3471)
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=13382.0;attach=3472)
i don't understand why this occurs looking into /apps/mc/libexec/mc/extfs.d/iso9660
-
Abnormis-
I will add some of those things like grep to mc that are small and give the fuller functionality. Give me a couple days or so.
-
thank you very much Jason, i already understood this :)
and we don't trying in any case to force you to rush this
but we here just try to find out some interesting points
-
It's all good. As I don't use mc personally, at least not until after packaging it, this has been an educational thread on what it uses and it's dependencies.
-
i found in the repo cdrtools.scm which i have not seen formerly
then it may really be enough convert coreutils.tcz to coreutils.scm
about which i had not thought earlier and not break head?
-
i'm sorry, i see that i was wrong because coreutils does not include grep and gawk
-
I haven't forgotten about this, I will put some more support binaries in hopefully today.
-
Added cdparanoia, isoinfo, p7zip, zip/unzip, gawk, unrar.
I don't use these functions with mc so please test and report any issues.
-
Hitting enter on an iso does not open the iso as a directory.
-
It opens an iso as a directory here, wonder what the issue may be.
-
It opens an iso as a directory here, wonder what the issue may be.
Is the problem that grep is not listed is /apps/mc/localbin?
Installing grep.tcz enables an ISO to be browsed as directories and files.
-
Ok, forgot to add grep, will add it in today.
-
egrep, fgrep, and grep added to localbin/ in mc.scm.
-
egrep, fgrep, and grep added to localbin/ in mc.scm.
When browsing an ISO an unmissable error message is obtained (see screenshot). Upon cancelling the message the ISO directories and files are then presented. Other than modifying the offending script is there a way to prevent the display of the message?
-
Hi SamK
Other than modifying the script, install grep.tcz.
-
Hi SamK
Other than modifying the script, install grep.tcz.
Hi Rich
Yes that does work. Have a browse back to post #43 in the thread, it was the aproach I used it to help diagnose the problem. As a fully self-contained app has been decided upon, the question is whether the misleading error message can be circumvented with grep built into the SCM as it is now.
Edit: typos
-
Hi SamK
The message is not misleading, the error just wasn't fatal so you could still view the ISO. There is still at least
one hard coded path to /usr/local/bin/ in the iso9660 script. Execute:
grep "usr/local/bin" /apps/mc/libexec/mc/extfs.d/*If the app were self contained, you probably shouldn't get any results. So, besides fixing the script or installing
grep, I guess the only other possibility is creating a link to busyboxes grep in /usr/local/bin/.
-
Hi Rich
The message is not misleading...
On the basis that it gives the impression that the requested action has/will fail, when it hasn't/won't, misleading is a fair description, however undesirable may be apt.
...I guess the only other possibility is creating a link to busyboxes grep in /usr/local/bin/.
This looks as though it will work. Not sure how it will be viewed in terms of an SCM creating the link during installation.
-
Hi SamK
Several other scripts in that directory call grep, but this is the only one that prepends a path onto it. The only
grep options I noticed being used in those scripts was -v, -i, -q, -s, and -c, which busybox grep supports.
Creating the link via the SCM is definitely not the right thing to do.
-
It appears the issue would go away if grep and those other utiliites were available in /apps/mc/localbin when mc was being built, so the scripts would be right. And preferably all build from scratch.
I will do that this week.
-
For now I fixed the iso9660 script by replacing /usr/local/bin/grep with grep, so the grep in the extension that is in the set path will be used.
-
Still doesn't open isos.
-
For now I fixed the iso9660 script by replacing /usr/local/bin/grep with grep, so the grep in the extension that is in the set path will be used.
Still doesn't open isos.
Applied the update and tested using Core-current.iso. Works fine here. No error messages received, simply able to browse the contents.
-
Perhaps this post might be helpful in getting a fully oprtational SCM
http://forum.tinycorelinux.net/index.php/topic,13543.msg75221.html#msg75221
Using the Debian based machine:
Pressing <Enter> produces error free browsing of tgz, tar.gz, rar, iso, 7z, zip
Using TCv4.5.4
Pressing <Enter> produces error free browsing of rar, iso, 7z
Fails on tgz, tar.gz, tar.bz2, zip
Error message tgz, tar.gz,
Cannot oper tar archive
NAME.tgz/ugz://
Error message tar.bz2,
Cannot oper tar archive
NAME.tar.bz2/ubz2://
Error message zip
Inconsistent extfs archive
sh: /apps/mc/libexec/mc/extfs.d/uzip: not found
-
The problem with the isos was:
Don't forget to delete the old ~/.config/mc.
-
The unzip issue shows that mc simply needs to be rebuilt, with it's proper dependencies in place.
It is a shame that the cause of the difficulty of this MC package perhaps appears to readers of this thread to be it's scm format, when 90% of it is rather due to the fact that I was unfamiliar with MC, it's dependencies, and it's usage.
I will rebuild it with it's deps included when the opportunity arises.
-
It is a shame that the cause of the difficulty of this MC package perhaps appears to readers of this thread to be it's scm format, when 90% of it is rather due to the fact that I was unfamiliar with MC, it's dependencies, and it's usage.
Your willingness to produce an SCM of an app you are unfamiliar with is helpful and deserving of praise and encouragement. This new to us all, there are bound to be minor hiccups along the way.
I would like to register my support and thanks for the effort you are making. The community is a better place as a result of it.
-
Ok, mc has been built form scratch with hopefully everything in place.
-
Oops, I need to make one adjustment, grep even when in /apps/mc/localbin is still listed in the scripts as /usr/local/bin/grep. I will fix that, and putting /apps/mc/localbin at the beginning of the PATH should fix it for subsequent rebuilds.
-
Uploaded.
-
Hi Jason W
On the off chance you did not catch it, a search for /usr/ in the mc scripts also turns up:
/usr/local/bin/perl
/usr/bin/zip
/usr/bin/unzip
/usr/bin/env python
/usr/bin/dpkg-repack
/usr/bin/apt-get
/usr/bin/dpkg-reconfigure
-
Thanks
Perl and python I think should be optional add ons.
I think adding to the info file of installing perl5.tcz or a python should do, as there is no scm version. The same would be true of mc.tcz.
I will fix the zip commands, which should be right naturally on next rebuild with /apps/mc/localbin at the front of PATH when building.
Thanks for the info, I will work in the Debian stuff next rebuild.
-
Here is the result of "grep /usr *" in the /apps/mc/libexec/mc/extfs.c directpry:
root@box:/tmp/2/mc/libexec/mc/extfs.d# grep /usr *
README:stored when configured or compiled, like /usr/local/libexec or /usr/libexec).
README:take whole tree and create .zip file from it. So /usr/zip:// will be
README:zipfile containing whole /usr tree.
a+:#! /usr/local/bin/perl -w
apt+:#! /usr/local/bin/perl
deb:#! /usr/local/bin/perl
deba:#! /usr/local/bin/perl
debd:#! /usr/local/bin/perl
debd: if ( -x "/usr/bin/dpkg-repack" ) {
debd: if ( -x "/usr/bin/apt-get" ) {
debd: if( -x "/usr/bin/dpkg-reconfigure" && -x "/var/lib/dpkg/info/$archive.config" ) {
dpkg+:#! /usr/local/bin/perl
mailfs:#! /usr/local/bin/perl -w
patchfs:#! /usr/local/bin/perl -w
rpms+:#! /usr/local/bin/perl
s3+:#!/usr/bin/env python
s3+:# Save as executable file /usr/libexec/mc/extfs/s3 (or wherever your mc expects to find extfs modules)
uzip:#! /usr/local/bin/perl -w
root@box:/tmp/2/mc/libexec/mc/extfs.d#
-
Hi Jason W
There are a few more under /usr/local/libexec/mc/ (I'm using the tcz as a reference)
/usr/local/libexec/mc/mc-wrapper.csh:/usr/local/bin/mc -P "$MC_PWD_FILE" $*
/usr/local/libexec/mc/mc-wrapper.sh:/usr/local/bin/mc -P "$MC_PWD_FILE" "$@"
/usr/local/libexec/mc/mc.csh:alias mc 'source /usr/local/libexec/mc/mc-wrapper.csh'
/usr/local/libexec/mc/mc.sh:alias mc='. /usr/local/libexec/mc/mc-wrapper.sh'
-
root@box:/apps/mc/libexec/mc# grep mc *
mc-wrapper.csh: setenv MC_PWD_FILE $TMPDIR/mc-$MC_USER/mc.pwd.$$
mc-wrapper.csh: setenv MC_PWD_FILE /tmp/mc-$MC_USER/mc.pwd.$$
mc-wrapper.csh:/apps/mc/localbin/mc -P "$MC_PWD_FILE" $*
mc-wrapper.sh:MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"
mc-wrapper.sh:/apps/mc/localbin/mc -P "$MC_PWD_FILE" "$@"
mc.csh:alias mc 'source /apps/mc/libexec/mc/mc-wrapper.csh'
mc.sh:alias mc='. /apps/mc/libexec/mc/mc-wrapper.sh'
-
Uploaded.
I will fix the zip commands, which should be right naturally on next rebuild with /apps/mc/localbin at the front of PATH when building.
Thanks for the info, I will work in the Debian stuff next rebuild.
Not sure what has been fixed so tested as follows. Updated to the latest mc. Tested only browsing of test archives by <Enter>key.
Success: 7z, rar, iso
Fail: tar.bz2, tar.gz, zip, bz2, gz
Error Messages
tar.bz2
Cannot open tar archive
test.tar.bz2/ubz2://
tar.gz
Cannot open tar archive
test.tar.bz2/ubz2://
zip
./test.zip
./test.zip: line 1: PK: not found
./test.zip: line 2: À½ï: not found
./test.zip: line 3: : not found
IHDR0WùsRGB®ÎébKGDÿÿÿ ½§: not found
./test.zip: line 4: }käiTXtCommentCreated: not found
./test.zip: line 6: syntax error: unexpected ")"
bz2
./test.bz2
3ìóowÊÍ}¾¸3.î ð÷9õïo%hÛåë»é:¹6úÑôè9=kZ·Wv¶³V˾Þóh¯YÃ8ä÷ºu立ϼfÁ½ßnòÝÛÞw»½ÛÏ%æÝÜq}ݵ¸ï¾ûçÏìã½Ùµw°Þ»Þr¦m: not found
./test.bz2: line 3: BZh91AY: not found
line 3: LG¦¢yOL@Ðd: not found
./test.bz2: ./test.bz2: ./test.bz2: line 3: e~òóÞó¾Ûeǽ÷Ç=ñç¼ÛSRHvTÅoZ_fªúÊI: not foundline 3: line 3: : not foundcan't open mC[ØoYëµÜÒÙ=îy½5m³aÖ} ^ëÛ6öwßz
í¾è»çîÙÙöîÆÃÛݶ¾.ï : no such file
./test.bz2: line 3: ȯ: not found
./test.bz2: line 3: á2ïôâìئ¤: not found
./test.bz2: line 3: T?ãÇz
ÆLMÏ÷gòÕìÍg8*ÂGi¶4
¦/·çbÜiM±: not found
./test.bz2: line 3: can't open @Èí»ËO++õ²P4¢UWK4b76ó: no such file
./test.bz2: line 3: SYÃn
¾3ïÿøyçÿÿ¿ïÿþ¿ÿÿþ: not found
./test.bz2: line 4: Jm°-%ß: not found
./test.bz2: line 5: syntax error: unexpected ")"
gz
./test.gz
./test.gz: line 1: syntax error: unexpected "("
-
I see the error messages too, but it still browses the archives. I will look more at it later.
-
I see the error messages too, but it still browses the archives. I will look more at it later.
Seems to be an official mc bug that has been fixed. Doesn't mention zip in the ticket.
https://www.midnight-commander.org/ticket/2785
Edit
The ticket also mentions the bug in relation to tar.xz. Do you see any value in adding this archiver to those included within the SCM?
-
Ok, I will rebuild with an updated version or a patch.
And add xz while I am at it.
-
hi jason w,
as you know the mc.tcz has the same problems...
will you be so kind and correct als the tcz-package?
thank you for your commitment and your contributions.
-
Hi netnomad,
The mc.tcz package is not mine, but if I find a solution here, the source and patches used can be used by the tcz packager to update mc.tcz with.
-
I see that the patch resulting from that bug report is in Arch Linux now, so an easy fix, rebuilding now and hopefully will just work.
-
Uploaded, seems to work, hope everything is good now.
-
i can confirm that the zip-error is solved :),
it seems to be a good piece of work.
-
Uploaded, seems to work, hope everything is good now.
i can confirm that the zip-error is solved :)
Using a very minimal testing set up, I obtain different results as reported below.
Set Up
ls /usr/local/tce.installed
Xlibs
Xorg-7.6-lib
Xprogs
Xvesa
expat2
fltk-1.10
fontconfig
jwm
kmaps
libfltk-xft
ls /apps
bin/
etc
mc/
share
Tests
Updated to the latest mc.scm, verified md5. Tested only browsing of test archives by <Enter> key.
Success:
7z, iso, rar, tar.bz2, tar.gz, tar.xz
Fail:
bz2, gz, zip
bz2, gz
The same results are obtained in a TC system and a system recently updated from Debian Testing. Perhaps this is the expected behaviour as they are both single file archivers rather than multiple directory/file archivers.
zip
In the Debian Testing system, browsing works as expected. In the TC test system it fails as follows:
No error message received. Archive not opened for browsing
Install zip-unzip.scm
Again, no error message received. Archive not opened for browsing
Reboot to test in a different configuration
(based on IceWM and Rox as they were handy from another project)
Error message received
Inconsistent extfs archive
sh: /apps/mc/libexec/mc/extfs.d/uzip: not found
Tentative conclusion
The current SCM is missing one or more dependencies. The reported success is loading these from other TCZs.
In the working Debian Testing system the mc version is reported as 3:4.8.3-3. Is this the same version as the SCM?
Almost there...
Edit: typos
-
My current version has the /apps/mc/libexec/mc/extfs.d/uzip file present. And it is present in the .list file on the server. Are you sure you have the latest?
-
My current version has the /apps/mc/libexec/mc/extfs.d/uzip file present. And it is present in the .list file on the server. Are you sure you have the latest?
SCM Update shows as upto date from ibiblio.
The md5 is 321088525288831f032d524c506b5172
My system also has /apps/mc/libexec/mc/extfs.d/uzip file present.
Edit:
Unzip (loaded by mc.scm) also seems to be working at the command line via
unzip -v test.zipas used in ~/.config/mc/mc.ext
-
The /apps/mc/libexec/mc/extfs.d/uzip file is a perl script, and it would be insane to include a perl instance in mc.scm. I will make a note in the info file about needing perl for that matter.
Also, I am at this point not too concerned about being able to browse single file gz or bz2 compressed files that are not archives. I will look more into it when I have some spare time though, maybe a simple solution like for the zip issue.
Thanks for all the testing, interest and feedback that helps to create a better result.
-
Reporting success.
perl5.tcz was added to the configuration used in reply #77 and the tests re-run.
Success:
7z, iso, rar, tar.bz2, tar.gz, tar.xz, zip, bz2, gz
Fail:
None
bz2, gz
perl5.tcz is not required for these to be successful.
It occurred to me that as these are designed to be used on a single file there would be little point in being able to browse the archive in the same way as archives of multiple directories and files, i.e. listing the contents then accessing a listed file.
To test, a plain text file was compressed as test.txt.bz2 and test.txt.gz. Pressing the <Enter> key on either of these displays the content of the compressed file (the text) rather than listing the the content of the archive (test.txt).
The /apps/mc/libexec/mc/extfs.d/uzip file is a perl script, and it would be insane to include a perl instance in mc.scm. I will make a note in the info file about needing perl for that matter.
Is there a case for perl5 to eventually be available as an SCM? If so, it will enable the consistency and ease of on-the-fly loading/unloading, also it would allow a user to add it to an app.scm.dep. Additionally, as the number of SCMs grow it is likely that it will be required by some of them.
Thanks for all the testing, interest and feedback that helps to create a better result.
Browsing back to the start of this topic, I was happy to accept the SCM at the stage of reply #9. At that point, the majority of the subsequently added archive handling was being achieved via scripts added to the MC User Menu. However, I agree that everyone's contribution and your persistence have produced a better result.
Thanks.
-
Is there a case for perl5 to eventually be available as an SCM? If so, it will enable the consistency and ease of on-the-fly loading/unloading, also it would allow a user to add it to an app.scm.dep. Additionally, as the number of SCMs grow it is likely that it will be required by some of them.
+1 (and maybe python could be considered as a candidate in the same fashion as well)
-
I will consider a perl5.scm, will look into it today. There is a python2.7 and python3.2 in the scm repo available.
-
Oops..
Brainfart, my bad!
Now I can even recall having been impressed that there were 2 different versions of python in the scm repo when I first saw...
-
perl5.scm is built and so far testing ok. Plan to upload shortly. report any bugs in a new perl5 thread.
Also, on the perl note, I have changed the shebangs of the perl scripts in mc from "/usr/local/bin/perl" to "/usr/bin/env perl" so either the tcz or scm version of perl will suffice. Testing, will upload soon.
-
Ok, perl5.scm uploaded, and mc.scm has been adjusted to use either perl5.scm or perl5.tcz as it's perl install.
-
"/usr/bin/env perl" does not work with mc, must include a hard path. So perl5.scm is chosen, with the path being /apps/bin/perl for the perl invocation.
-
Ok, perl5.scm uploaded...
Unable to update mc.scm from ibiblio. SCMApps consistently returns "Failed". As a test, xz.scm downloads OK, so the symptoms I see appear to be related to the avialable mc.scm update.
-
Coreutils which I believe is now part of mc breaks Apps GUI.
Use ab or tce-load as a workaround.
The issue is fixed but waiting on ibiblio for available space to post a bug fix release.
-
Unable to update mc.scm from ibiblio. SCMApps consistently returns "Failed". As a test, xz.scm downloads OK, so the symptoms I see appear to be related to the avialable mc.scm update.
Coreutils which I believe is now part of mc breaks Apps GUI.
Use ab or tce-load as a workaround.
The issue is fixed but waiting on ibiblio for available space to post a bug fix release.
After an upgrade to 4.5.6 and xprogs mc.scm still fails to update.
With mc.scm uninstalled "SCMApps-->Check for Updates" shows a pending update for MC. Attemping to update via "Process Selected Items" produces a "Failed" message.
mc.scm and mc.smc.md5.txt, were then deleted from the system and downloaded again via "Download Only" i.e. not installed. The md5 is 75f1e364da34bc157361512fe0f68986. A check for pending updates again lists mc.scm which fails as described above.
-
A check for pending updates again lists mc.scm which fails as described above.
I was never able to download this update, however trying again a day later the update is no longer available. Is the md5 mentioned in reply #90 the current release?
On reviewing the results to date, the report of successfully browsing archives (reply #81) is inaccurate. They were not done in the usual minimal testing environment (reply #77), but in another TC project which loaded rox-filer.tcz. This invalidated the archive browsing results.
Using the minimal testing environment plus perl5.tcz and rox-filer.tcz the results reported in reply #81 are obtained.
Using the minimal testing environment plus perl5.scm produces the following.
Tested only browsing of test archives by <Enter> key.
Success:
7z, iso, rar, tar.bz2, tar.gz, tar.xz
Fail:
bz2, gz, zip
No error messages are obtained.
It seems likely that one or more deps are still required in mc.scm that are provided by ROX for bz2 and gz. Possibly something is also awry with mc/perl5 SCMs for zip.
-
The space issue is still ongoing.
-
I don't have issues browsing zip files, but I will look into what is up with the bz2 and gzip browsing. The zip issue should be fine when the update is able to be fetched.
-
With bz2 files there is a very simple fix. It needs the file command, which is inside the rox-filer.scm but it is not in path, somehow it gets used though.
I will build file inside the mc extension, and hopefully this completes the saga. It has been educational in terms of mc and what it needs to be fully functional.
-
Updated extension has been uploaded.
Also, it updated successfully via ScmApps.
-
Updated extension has been uploaded.
Also, it updated successfully via ScmApps.
Update obtained OK.
Installed also perl5.scm. Tests re-run in the minimal testing environment.
Reporting success.
Success:
7z, iso, rar, tar.bz2, tar.gz, tar.xz, zip, bz2, gz
Fail:
None
One last item, the SCM-Apps info tab displays no information. It was just a quick check to see if a note had been added regarding the optional use of perl5.scm.
...hopefully this completes the saga.
It has been quite a journey. It is a relief to get to the end, especially in view of achieving such a worthwhile outcome. Hopefully the experience will ease the improvement of existing and creation of new SCMs.
-
ScmApps doesn't display info file for mc.scm
-
Oops, somehow the info file got replaced with a blank file. I will fix that by tonight.
-
Original lost, but a basic one is in place. I will fill it out further to account for extension contents later.
-
Original lost, but a basic one is in place. I will fill it out further to account for extension contents later.
How much later?
-
Done.
-
The /apps/mc/libexec/mc/extfs.d/uzip file is a perl script, and it would be insane to include a perl instance in mc.scm. I will make a note in the info file about needing perl for that matter.
Might it also be worth adding the above to the info file?
-
Done, thanks.