Request Midnight Commander File Manager

[Jason W]

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.

[SamK]

...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.
   

[Jason W]

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.

[AbNoRMiS]

...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

[Jason W]

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.

[SamK]

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?

[AbNoRMiS]

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

[bmarkus]

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.

[AbNoRMiS]

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

[bmarkus]

This is the beauty of the flexible and modular system

[AbNoRMiS]

and what to do?

[SamK]

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

Code: [Select]

ls -1a | grep ash

.ash_history
.ashrc
.bashrc
Note you may need key-combination CTL+o to view the result
   

[AbNoRMiS]

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




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

[Rich]

Hi AbNoRMiS
That message only suggests that grep can't be found, not that busybox grep won't work.

[AbNoRMiS]

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