EXPIRE key seconds

Set a timeout on 

key

. After the timeout has expired, the key will automatically be deleted. A key with an associated timeout is often said to be volatile in Redis terminology.

The timeout will only be cleared by commands that delete or overwrite the contents of the key, including DELSETGETSET and all the 

*STORE

commands. This means that all the operations that conceptually alter the value stored at the key without replacing it with a new one will leave the timeout untouched. For instance, incrementing the value of a key with INCR, pushing a new value into a list with LPUSH, or altering the field value of a hash with HSET are all operations that will leave the timeout untouched.

The timeout can also be cleared, turning the key back into a persistent key, using the PERSIST command.

If a key is renamed with RENAME, the associated time to live is transferred to the new key name.

If a key is overwritten by RENAME, like in the case of an existing key 

Key_A

that is overwritten by a call like 

RENAME Key_B Key_A

, it does not matter if the original 

Key_A

 had a timeout associated or not, the new key 

Key_A

 will inherit all the characteristics of 

Key_B

.

Note that calling EXPIRE/PEXPIRE with a non-positive timeout orEXPIREAT/PEXPIREAT with a time in the past will result in the key beingdeleted rather than expired (accordingly, the emitted key event will be 

del

, not 

expired

).

Refreshing expires

It is possible to call EXPIRE using as argument a key that already has an existing expire set. In this case the time to live of a key is updated to the new value. There are many useful applications for this, an example is documented in the Navigation session pattern section below.

Differences in Redis prior 2.1.3

In Redis versions prior 2.1.3 altering a key with an expire set using a command altering its value had the effect of removing the key entirely. This semantics was needed because of limitations in the replication layer that are now fixed.

EXPIRE would return 0 and not alter the timeout for a key with a timeout set.

Return value

Integer reply, specifically:

  • 1

     if the timeout was set.

  • 0

     if 

    key

     does not exist.

Examples

redis> SET mykey “Hello”

"OK"

redis> EXPIRE mykey 10

(integer) 1

redis> TTL mykey

(integer) 10

redis> SET mykey “Hello World”

"OK"

redis> TTL mykey

(integer) -1
redis> 

Pattern: Navigation session

Imagine you have a web service and you are interested in the latest N pagesrecently visited by your users, such that each adjacent page view was not performed more than 60 seconds after the previous. Conceptually you may consider this set of page views as a Navigation session of your user, that may contain interesting information about what kind of products he or she is looking for currently, so that you can recommend related products.

You can easily model this pattern in Redis using the following strategy: every time the user does a page view you call the following commands:


MULTI
RPUSH pagewviews.user:<userid> http://.....
EXPIRE pagewviews.user:<userid> 60
EXEC

If the user will be idle more than 60 seconds, the key will be deleted and only subsequent page views that have less than 60 seconds of difference will be recorded.

This pattern is easily modified to use counters using INCR instead of lists using RPUSH.

Appendix: Redis expires

Keys with an expire

Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command.

The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed.

The key time to live can be updated or entirely removed using the EXPIREand PERSIST command (or other strictly related commands).

Expire accuracy

In Redis 2.4 the expire might not be pin-point accurate, and it could be between zero to one seconds out.

Since Redis 2.6 the expire error is from 0 to 1 milliseconds.

Expires and persistence

Keys expiring information is stored as absolute Unix timestamps (in milliseconds in case of Redis version 2.6 or greater). This means that the time is flowing even when the Redis instance is not active.

For expires to work well, the computer time must be taken stable. If you move an RDB file from two computers with a big desync in their clocks, funny things may happen (like all the keys loaded to be expired at loading time).

Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.

How Redis expires keys

Redis keys are expired in two ways: a passive way, and an active way.

A key is passively expired simply when some client tries to access it, and the key is found to be timed out.

Of course this is not enough as there are expired keys that will never be accessed again. These keys should be expired anyway, so periodically Redis tests a few keys at random among keys with an expire set. All the keys that are already expired are deleted from the keyspace.

Specifically this is what Redis does 10 times per second:

  1. Test 20 random keys from the set of keys with an associated expire.
  2. Delete all the keys found expired.
  3. If more than 25% of keys were expired, start again from step 1.

This is a trivial probabilistic algorithm, basically the assumption is that our sample is representative of the whole key space, and we continue to expire until the percentage of keys that are likely to be expired is under 25%

This means that at any given moment the maximum amount of keys already expired that are using memory is at max equal to max amount of write operations per second divided by 4.

How expires are handled in the replication link and AOF file

In order to obtain a correct behavior without sacrificing consistency, when a key expires, a DEL operation is synthesized in both the AOF file and gains all the attached replicas nodes. This way the expiration process is centralized in the master instance, and there is no chance of consistency errors.

However while the replicas connected to a master will not expire keys independently (but will wait for the DEL coming from the master), they’ll still take the full state of the expires existing in the dataset, so when a replica is elected to master it will be able to expire the keys independently, fully acting as a master.

ubuntu下安装 mod_wsgi

mod_wsgi
1.pip install mod_wsgi
报错:
Collecting mod_wsgi
  Downloading mod_wsgi-4.5.18.tar.gz (2.5MB)
    100% |████████████████████████████████| 2.5MB 21kB/s 
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File “”, line 1, in
      File “/tmp/pip-build-lemsW_/mod-wsgi/setup.py”, line 164, in
        ‘missing Apache httpd server packages.’ % APXS)
    RuntimeError: The ‘apxs’ command appears not to be installed or is not executable. Please check the list of prerequisites in the documentation for this package and install any missing Apache httpd server packages.
    
    —————————————-
Command “python setup.py egg_info” failed with error code 1 in /tmp/pip-build-lemsW_/mod-wsgi/
执行:
sudo apt-get install apache2-dev
再次安装mod_wsgi:
well@well:/usr/local/lib$ sudo pip install mod_wsgi
The directory ‘/home/well/.cache/pip/http’ or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
The directory ‘/home/well/.cache/pip’ or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
Collecting mod_wsgi
  Downloading mod_wsgi-4.5.18.tar.gz (2.5MB)
    100% |████████████████████████████████| 2.5MB 47kB/s 
Installing collected packages: mod-wsgi
  Running setup.py install for mod-wsgi … done
Successfully installed mod-wsgi-4.5.18
安装成功。

微信网页开发,获取access_token并设置定时刷新,PHP

原理:用微信公众号文档的教程获取access_token,编写php脚本,定时刷新,并将值存入数据库,需要用的话就直接从数据库下载,不必再次获取access_token的值。

直接上代码

第一段代码,根据微信公众号提供的教程,获取access_token的值。

<?php
$token_access_url = “https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=此处为你的APPID&secret=此处为你的APP密码”;
$res = file_get_contents($token_access_url);
$result = json_decode($res, true); //接受一个 JSON 格式的字符串并且把它转换为 PHP 变量
$access_token = $result[‘access_token’];
// echo $access_token;
?>
第二段代码。将值存入数据库并定时刷新

<?php
header(“Content-type:text/html;charset=utf-8″);
$time=1.8*60*60;//此处设置刷新时间,我设置的是1.8小时,因为设置两小时的话可能会有延迟,导致业务无法进行,尽管微信公众号规定到期后五分钟,新旧access_token都可以使用
$url=”http://”.$_SERVER[‘HTTP_HOST’].$_SERVER[‘REQUEST_URI’];//当前文件的url
include_once ‘access_token_yuanshishuju.php’;//此处插入第一段获取access_token的php文件
include_once ‘coom.php’;//此处插入mysql连接设置文件
mysqli_query($conn , “set names utf8”);
$sql = “UPDATE 表名
SET 字段名= ‘$access_token’
WHERE id=1”;
mysqli_select_db( $conn, ‘数据库名’ );
$retval = mysqli_query( $conn, $sql );
if(! $retval )
{
die(‘无法更新数据: ‘ . mysqli_error($conn));
}
echo “数据更新成功\n”;
mysqli_close($conn);//access_token的值存入数据库
sleep($time);
file_get_contents($url);//此处设置定时刷新,需打开一次该文件,打开后会一直显示刷新状态,然后关闭就行了 ,会一直自己运行,修改本文件后需再一次打开本文件,保证一直刷新
?>
第三段代码,从数据库获取access_token的值

<?php
include_once ‘coom.php’;//数据库连接设置
mysqli_query($conn , “set names utf8”);
$sql = ‘SELECT 字段名
FROM 表名
where id = 1’;
mysqli_select_db( $conn, ‘数据库名’ );
$retval = mysqli_query( $conn, $sql );
if(! $retval )
{
die(‘无法查询数据: ‘ . mysqli_error($conn));
}
$row = mysqli_fetch_array($retval, MYSQL_ASSOC);
$access_token = $row[‘access_token’];//获取该值
mysqli_close($conn);
// echo $access_token;
?>

———————
作者:前端卡卡
来源:CSDN
原文:https://blog.csdn.net/weixin_41797287/article/details/80334195
版权声明:本文为博主原创文章,转载请附上博文链接!

Ubuntu 18.04 安装 Apache, MySQL, PHP7, phpMyAdmin

1、准备

更新软件源中的所有软件列表(必须)
sudo apt update

更新软件(建议)
sudo apt upgrade

更新系统版本(非必要时,不建议升级)
sudo apt dist-upgrade
2、安装Apache

sudo apt install apache2
3、安装PHP

sudo apt install php
4、安装MySQL

sudo apt install mysql-server php-mysql
5、配置MySQL

mysql -u root
use mysql;
update mysql.user <span class=”hljs-built_in”>set</span> authentication_string=PASSWORD(<span class=”hljs-string”>’你的密码'</span>), plugin=<span class=”hljs-string”>’mysql_native_password'</span> <span class=”hljs-built_in”>where</span> user=<span class=”hljs-string”>’root'</span>;
flush privileges;
quit;
sudo service mysql stop
sudo service mysql start
6、附加安装

sudo apt install libapache2-mod-php php-mysql php-curl php-gd
7、安装phpMyAdmin

sudo apt install phpmyadmin
8、启用mod_rewrite模块

sudo a2enmod rewrite
sudo service apache2 restart
9、配置

编辑apache2.conf,/var/www/路径可修改(如修改为/data/www/),启用RewriteEngine
<Directory /var/www>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
RewriteEngine On
</Directory>

编辑 /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin service@example.com
DocumentRoot /var/www/example
<Directory />
DirectoryIndex index.html index.php
Options FollowSymLinks
AllowOverride All
RewriteEngine On
</Directory>
ErrorLog /var/log/apache2/example_error.log
CustomLog /var/log/apache2/example_access.log combined
</VirtualHost>
10、权限设置

改变/var/www/目录所有者为ubuntu(腾讯云Ubuntu默认用户)
sudo chown -R ubuntu /var/www/

设置网站权限
chmod 755 /var/www/
chmod 777 /var/www/example/application
chmod 777 /var/www/example/uploads -R
chmod 777 /var/www/example/runtime -R

———————
作者:宝庆陈
来源:CSDN
原文:https://blog.csdn.net/sanve/article/details/80770675
版权声明:本文为博主原创文章,转载请附上博文链接!

使用 pip 安装 TensorFlow

使用 pip 安装 TensorFlow

使用 pip 安装 TensorFlow

TensorFlow 2.0 Alpha 版现已推出

  • tensorflow==2.0.0-alpha0

     – 仅支持 CPU 的预览 TF 2.0 Alpha 版(不稳定)

  • tensorflow==2.0.0-alpha0-gpu

     – 支持 GPU 的预览 TF 2.0 Alpha 版(不稳定,适用于 Ubuntu 和 Windows)

可用软件包

  • tensorflow

     – 仅支持 CPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tensorflow-gpu

     – 支持 GPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tf-nightly

     – 仅支持 CPU 的预览每夜版(不稳定)

  • tf-nightly-gpu

     – 支持 GPU 的预览每夜版(不稳定,适用于 Ubuntu 和 Windows)

系统要求

  • Ubuntu 16.04 或更高版本(64 位)
  • macOS 10.12.6 (Sierra) 或更高版本(64 位)(不支持 GPU)
  • Windows 7 或更高版本(64 位)(仅支持 Python 3)
  • Raspbian 9.0 或更高版本

硬件要求

  • 从 TensorFlow 1.6 开始,二进制文件使用 AVX 指令,这些指令可能无法在旧版 CPU 上运行。
  • 阅读 GPU 支持指南,以在 Ubuntu 或 Windows 上设置支持 CUDA® 的 GPU 卡。

1. 在系统上安装 Python 开发环境

 检查是否已配置 Python 环境:

    

<span class="pln">python3 </span><span class="pun">--</span><span class="pln">version</span>
   
<span class="pln">pip3 </span><span class="pun">--</span><span class="pln">version</span>
   
<span class="pln">virtualenv </span><span class="pun">--</span><span class="pln">version</span>
   

如果已安装这些软件包,请跳至下一步。
否则,请安装 Pythonpip 软件包管理器和 Virtualenv

    

<span class="pln">sudo apt update</span>
   
<span class="pln">sudo apt install python3</span><span class="pun">-</span><span class="pln">dev python3</span><span class="pun">-</span><span class="pln">pip</span>
   
<span class="pln">sudo pip3 install </span><span class="pun">-</span><span class="pln">U virtualenv  </span><span class="com"># system-wide install</span>
   

2. 创建虚拟环境(推荐)

Python 虚拟环境用于将软件包安装与系统隔离开来。

创建一个新的虚拟环境,方法是选择 Python 解析器并创建一个 

./venv

 目录来存放它:

virtualenv --system-site-packages -p python3 ./venv

使用特定于 shell 的命令激活该虚拟环境:

source ./venv/bin/activate  # sh, bash, ksh, or zsh

当 virtualenv 处于有效状态时,shell 提示符带有 

(venv)

 前缀。

在不影响主机系统设置的情况下,在虚拟环境中安装软件包。首先升级 

pip

    

<span class="pln">pip install </span><span class="pun">--</span><span class="pln">upgrade pip</span>
   
<span class="pln">pip list  </span><span class="com"># show packages installed within the virtual environment</span>
   

之后要退出 virtualenv,请使用以下命令:

deactivate  # don't exit until you're done using TensorFlow

3. 安装 TensorFlow pip 软件包

从 PyPI 中选择以下某个 TensorFlow 软件包进行安装:

  • tensorflow

     – 仅支持 CPU 的最新稳定版(建议新手使用)

  • tensorflow-gpu

     – 支持 GPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tf-nightly

     – 仅支持 CPU 的预览每夜版(不稳定)

  • tf-nightly-gpu

     – 支持 GPU 的预览每夜版(不稳定,适用于 Ubuntu 和 Windows)

  • tensorflow==2.0.0-alpha0

     – 仅支持 CPU 的预览 TF 2.0 Alpha 版(不稳定)

  • tensorflow-gpu==2.0.0-alpha0

     – 支持 GPU 的预览 TF 2.0 Alpha 版(不稳定,Ubuntu 和 Windows)

pip install --upgrade tensorflow

验证安装效果:

python -c "import tensorflow as tf; tf.enable_eager_execution(); print(tf.reduce_sum(tf.random_normal([1000, 1000])))"

软件包位置

有几个安装机制需要您提供 TensorFlow Python 软件包的网址。您需要根据 Python 版本指定网址。

版本 网址
Linux
Python 2.7(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp27-none-linux_x86_64.whl
Python 2.7(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp27-none-linux_x86_64.whl
Python 3.4(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp34-cp34m-linux_x86_64.whl
Python 3.4(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp34-cp34m-linux_x86_64.whl
Python 3.5(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp35-cp35m-linux_x86_64.whl
Python 3.5(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp35-cp35m-linux_x86_64.whl
Python 3.6(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp36-cp36m-linux_x86_64.whl
Python 3.6(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp36-cp36m-linux_x86_64.whl
macOS(仅支持 CPU)
Python 2.7 https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-1.12.0-py2-none-any.whl
Python 3.4、3.5、3.6 https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-1.12.0-py3-none-any.whl
Windows
Python 3.5(仅支持 CPU) https://storage.googleapis.com/tensorflow/windows/cpu/tensorflow-1.12.0-cp35-cp35m-win_amd64.whl
Python 3.5(支持 GPU) https://storage.googleapis.com/tensorflow/windows/gpu/tensorflow_gpu-1.12.0-cp35-cp35m-win_amd64.whl
Python 3.6(仅支持 CPU) https://storage.googleapis.com/tensorflow/windows/cpu/tensorflow-1.12.0-cp36-cp36m-win_amd64.whl
Python 3.6(支持 GPU) https://storage.googleapis.com/tensorflow/windows/gpu/tensorflow_gpu-1.12.0-cp36-cp36m-win_amd64.whl

FLASK + Apache + mod_wsgi + ubuntu18.04 部署笔记

将FLASK开发的网站部署成功,之所以采取此方案是因为想同时运行一个apache+php的网站,python用的是UBUNTU18.04自带的3.6.5

1. 安装apache


sudo apt install apache2
sudo apt install apache2-dev

2. 安装pip3

UBUNTU18.04自带python3但是不带pip


sudo apt install python3-pip

3. 将mod_wsgi安装到python中


pip3 install mod_wsgi

注意:必须安装apache2和apache2-dev后才能安装成功。

4. 在apache中启用安装到python中的mod_wsgi

执行

mod_wsgi-express module-config

输出如下所示的文字,将其复制


LoadModule wsgi_module <span class="hljs-string">"/your/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so"</span>
WSGIPythonHome <span class="hljs-string">"/usr"</span>

/etc/apache2/mods-available/

新建配置文件


nano /etc/apache2/mods-available/wsgi.load

将刚才复制的内容粘贴进来,保存并退出

在终端中执行如下命令,启用wsgi模块


sudo a2enmod wsgi
systemctl restart apache2

5 配置python虚拟环境

python虚拟环境的选择有很多,我用的是pyvenv,由于ubuntu18.04默认不安装,所以首先


sudo apt install python3-venv

然后执行


pyvenv path/to/venv/

配置python虚拟环境

6 编写

.wsgi

文件

在flask项目目录下新建一个

.wsgi

文件,里面包含wsgi启动网站所需的applicaiton对象,文件内容如下


    <span class="hljs-keyword">import</span> sys
    sys.path.insert(<span class="hljs-number">0</span>, <span class="hljs-string">'/path/to/the/application'</span>)
     <span class="hljs-keyword">from</span> yourapplication <span class="hljs-keyword">import</span> app <span class="hljs-keyword">as</span> application

7 编写apache虚拟站点配置文件

/etc/apache2/site-available

新建配置文件


nano /etc/apache2/site-available/yoursite.conf

编辑文件


<span class="hljs-tag">&lt;<span class="hljs-name">VirtualHost</span> *<span class="hljs-attr">:80</span>&gt;</span>
    ServerName example.com
    # python-home指定python虚拟目录的位置
    WSGIDaemonProcess yourapplication python-home=/path/to/env/
    WSGIScriptAlias / /path/to/yourapplication/yourapplication.wsgi
        <span class="hljs-tag">&lt;<span class="hljs-name">Directory</span> /<span class="hljs-attr">path</span>/<span class="hljs-attr">to</span>/<span class="hljs-attr">yourapplication</span>&gt;</span>
        WSGIProcessGroup yourapplication
        WSGIApplicationGroup %{GLOBAL}
        Require all granted
    <span class="hljs-tag">&lt;/<span class="hljs-name">Directory</span>&gt;</span>
<span class="hljs-tag">&lt;/<span class="hljs-name">VirtualHost</span>&gt;</span>

8 致此配置完毕,最后一点小问题

因为数据库是sqlite,配置完毕后出现了

attempt to write a readonly database

错误,经过搜索发现是文件读写权限的问题,可以将数据库文件及所在文件夹的所有者更改www-data来解决


sudo chown www-data your/database/
sudo chown www-data your/database/database

9 参考文章

  1. flask文档 http://flask.pocoo.org/docs/1.0/deploying/mod_wsgi/
  2. mod_wsgi文档 http://modwsgi.readthedocs.io/en/develop/project-status.html
  3. mod_wsgi pypi页面 https://pypi.org/project/mod_wsgi/
  4. 问题解决:SQLite:DatabaseError : attempt to write a readonly databas http://ju.outofmemory.cn/entry/147685

作者:美妙的旋律A
链接:https://www.jianshu.com/p/603e8c29abec
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

Configuration Guidelines

Configuration Guidelines

The purpose of this document is to detail the basic configuration steps required for running WSGI applications with mod_wsgi.

The WSGIScriptAlias Directive

Configuring Apache to run WSGI applications using mod_wsgi is similar to how Apache is configured to run CGI applications. To streamline this task however, an additional configuration directive called WSGIScriptAlias is provided. Like the ScriptAlias directive for CGI scripts, the mod_wsgi directive combines together a number of steps so as to reduce the amount of configuration required.

The first way of using the WSGIScriptAlias directive to indicate the WSGI application to be used, is to associate a WSGI application against a specific URL prefix:

WSGIScriptAlias /myapp /usr/local/wsgi/scripts/myapp.wsgi

The last option to the directive in this case must be a full pathname to the actual code file containing the WSGI application. A trailing slash should never be added to the last option when it is referring to an actual file.

The WSGI application contained within the code file specified should be called ‘application’. For example:

def application(environ, start_response):
    status = '200 OK'
    output = b'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

Note that an absolute pathname to a WSGI script file must be provided. It is not possible to specify an application by Python module name alone. A full path is used for a number of reasons, the main one being so that all the Apache access controls can still be applied to indicate who can actually access the WSGI application. Because these access controls will apply, if the WSGI application is located outside of any directories already known to Apache, it will be necessary to tell Apache that files within that directory can be used. To do this the Directory directive must be used:

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

Note that Apache access control directives such as Order and Allow, or Require in the case of Apache 2.4 or newer, should nearly always be applied to Directory and never to a Location. Adding them to a Location would not be regarded as best practice and would potentially weaken the security of your Apache server, especially where the Location was for ‘/’.

As for CGI scripts and the ScriptAlias directive, it is not necessary to have used the Options directive to enable the ExecCGI directive. This is because it is automatically implied from the use of the WSGIScriptAlias directive that the script must be executable.

For WSGIScriptAlias, to mount a WSGI application at the root of the web site, simply use ‘/’ as the mount point:

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

If you need to mount multiple WSGI applications, the directives can be listed more than once. When this occurs, those occuring first are given precedence. As such, those which are mounted at what would be a sub URL to another WSGI application, should always be listed earlier:

WSGIScriptAlias /wiki /usr/local/wsgi/scripts/mywiki.wsgi
WSGIScriptAlias /blog /usr/local/wsgi/scripts/myblog.wsgi
WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

The second way of using the WSGIScriptAlias directive is to use it to map to a directory containing any number of WSGI applications:

WSGIScriptAlias /wsgi/ /usr/local/wsgi/scripts/

When this is used, the next part of the URL after the URL prefix is used to identify which WSGI application script file within the target directory should be used. Both the mount point and the directory path must have a trailing slash.

If you want WSGI application scripts to use an extension, but don’t wish to have that extension appear in the URL, then it is possible to use the WSGIScriptAliasMatch directive instead:

WSGIScriptAliasMatch ^/wsgi/([^/]+) /usr/local/wsgi/scripts/$1.wsgi

In this case, any path information appearing after the URL prefix, will be mapped to a corresponding WSGI script file in the directory, but with a ‘.wsgi’ extension. The extension would though not need to be included in the URL.

In all ways that the WSGIScriptAlias can be used, the target script is not required to have any specific extension type and in particular it is not necessary to use a ‘.py’ extension just because it contains Python code. Because the target script is not treated exactly like a traditional Python module, if an extension is used, it is recommended that ‘.wsgi’ be used rather than ‘.py’.

The Apache Alias Directive

Although the WSGIScriptAlias directive is provided, the traditional Alias directive can still be used to enable execution of WSGI applications for specific URLs. The equivalent such configuration for:

WSGIScriptAlias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

using the Alias directive would be:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI

SetHandler wsgi-script

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

The additional steps required in this case are to enable the ability to execute CGI like scripts using the Options directive and define the Apache handler as ‘wsgi-script’.

If wishing to hold a mixture of static files, normal CGI scripts and WSGI applications within the one directory, the AddHandler directive can be used instead of the SetHandler directive to distinguish between the various resource types based on resource extension:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

For whatever extension you use to identify a WSGI script file, ensure that you do not have a conflicting definition for that extension marking it as a CGI script file. For example, if you previously had all ‘.py’ files being handled as ‘cgi-script’, consider disabling that before marking ‘.py’ file as then being handled as ‘wsgi-script’ file in same context. If both are defined in same context, which is used will depend on the order of the directives and the wrong handler may be selected.

Because an extension is required to determine whether a script should be processed as a CGI script versus a WSGI application, the extension would need to appear in the URL. If this is not desired, then add the MultiViews option and MultiviewsMatch directive:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI MultiViews
MultiviewsMatch Handlers

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

Adding of MultiViews in this instance and allowing multiviews to match Apache handlers will allow the extension to be dropped from the URL. Provided that for each resource there is only one alternative, Apache will then automatically select either the CGI script or WSGI application as appropriate for that resource. Use of multiviews in this way would make it possible to transparently migrate from CGI scripts to WSGI applications without the need to change any URLs.

A benefit of using the AddHandler directive as described above, is that it also allows a directory index page or directory browsing to be enabled for the directory. To enable directory browsing add the Indexes option:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI Indexes

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

If a directory index page is enabled, it may refer to either a static file, CGI or WSGI application. The DirectoryIndex directive should be used to designate what should be used for the index page:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI Indexes

DirectoryIndex index.html index.wsgi index.cgi

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

Using AddHandler or SetHandler to configure a WSGI application can also be done from within the ‘.htaccess’ file located within the directory which a URL maps to. This will however only be possible where the directory has been enabled to allow these directives to be used. This would be done using the AllowOverride directive and enabling FileInfo for that directory. It would also be necessary to allow the execution of scripts using the Options directive by listing ExecCGI:

Alias /site/ /usr/local/wsgi/site/

<Directory /usr/local/wsgi/site>
AllowOverride FileInfo
Options ExecCGI MultiViews Indexes
MultiviewsMatch Handlers

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

This done, the ‘.htaccess’ file could then contain:

DirectoryIndex index.html index.wsgi index.cgi

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

Note that the DirectoryIndex directive can only be used to designate a simple WSGI application which returns a single page for when the URL maps to the actual directory. Because the DirectoryIndex directive is not applied when the URL has additional path information beyond the leading portion of the URL which mapped to the directory, it cannot be used as a means of making a complex WSGI application responding to numerous URLs appear at the root of a server.

When using the AddHandler directive, with WSGI applications identified by the extension of the script file, the only way to make the WSGI application appear as the root of the server is to perform on the fly rewriting of the URL internal to Apache using mod_rewrite. The required rules for mod_rewrite to ensure that a WSGI application, implemented by the script file ‘site.wsgi’ in the root directory of the virtual host, appears as being mounted on the root of the virtual host would be:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]

Do note however that when the WSGI application is executed for a request the ‘SCRIPT_NAME’ variable indicating what the mount point of the application was will be ‘/site.wsgi’. This will mean that when a WSGI application constructs an absolute URL based on ‘SCRIPT_NAME’, it will include ‘site.wsgi’ in the URL rather than it being hidden. As this would probably be undesirable, many web frameworks provide an option to override what the value for the mount point is. If such a configuration option isn’t available, it is just as easy to adjust the value of ‘SCRIPT_NAME’ in the ‘site.wsgi’ script file itself:

def _application(environ, start_response):
    # The original application.
    ...

import posixpath

def application(environ, start_response):
    # Wrapper to set SCRIPT_NAME to actual mount point.
    environ['SCRIPT_NAME'] = posixpath.dirname(environ['SCRIPT_NAME'])
    if environ['SCRIPT_NAME'] == '/':
        environ['SCRIPT_NAME'] = ''
    return _application(environ, start_response)

This wrapper will ensure that ‘site.wsgi’ never appears in the URL as long as it wasn’t included in the first place and that access was always via the root of the web site instead.

Application Configuration

If it is necessary or desired to be able to pass configuration information through to a WSGI application from the Apache configuration file, then the SetEnv directive can be used:

WSGIScriptAlias / /usr/local/wsgi/scripts/demo.wsgi

SetEnv demo.templates /usr/local/wsgi/templates
SetEnv demo.mailhost mailhost
SetEnv demo.debugging 0

Any such variables added using the SetEnv directive will be automatically added to the WSGI environment passed to the application when executed.

Note that the WSGI environment is passed upon each request to the application in the ‘environ’ argument of the application object. This environment is totally unrelated to the process environment which is kept in ‘os.environ’. The SetEnv directive has no effect on ‘os.environ’ and there is no way through Apache configuration directives to affect what is in the process environment.

If needing to dynamically set variables based on some aspects of the request itself, the RewriteRule directive may also be useful in some cases as an avenue to set application configuration variables.

For example, to enable additional debug only when the client is connecting from the localhost, the following might be used:

SetEnv demo.debugging 0

RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^127.0.0.1$
RewriteRule . - [E=demo.debugging:1]

More elaborate schemes involving RewriteMap could also be employed.

Where SetEnv and RewriteRule are insufficient, then any further application configuration should be injected into an application using a WSGI application wrapper within the WSGI application script file:

def _application(environ, start_response):
    ...

def application(environ, start_response):
    if environ['REMOTE_ADDR'] in ['127.0.0.1']:
        environ['demo.debugging'] = '1'
    return _application(environ, start_response)

User Authentication

As is the case when using CGI scripts with Apache, authorisation headers are not passed through to WSGI applications. This is the case, as doing so could leak information about passwords through to a WSGI application which should not be able to see them when Apache is performing authorisation.

Unlike CGI scripts however, when using mod_wsgi, the WSGIPassAuthorization directive can be used to control whether HTTP authorisation headers are passed through to a WSGI application in the 

<span class="pre">HTTP_AUTHORIZATION</span>

 variable of the WSGI application environment when the equivalent HTTP request headers are present. This option would need to be set to 

<span class="pre">On</span>

 if the WSGI application was to handle authorisation rather than Apache doing it:

WSGIPassAuthorization On

If Apache is performing authorisation and not the WSGI application, a WSGI application can still find out what type of authorisation scheme was used by checking the variable 

<span class="pre">AUTH_TYPE</span>

 of the WSGI application environment. The login name of the authorised user can be determined by checking the variable 

<span class="pre">REMOTE_USER</span>

.

Hosting Of Static Files

When the WSGIScriptAlias directive is used to mount an application at the root of the web server for a host, all requests for that host will be processed by the WSGI application. If is desired for performance reasons to still use Apache to host static files associated with the application, then the Alias directive can be used to designate the files and directories which should be served in this way:

Alias /robots.txt /usr/local/wsgi/static/robots.txt
Alias /favicon.ico /usr/local/wsgi/static/favicon.ico

AliasMatch /([^/]*\.css) /usr/local/wsgi/static/styles/$1

Alias /media/ /usr/local/wsgi/static/media/

<Directory /usr/local/wsgi/static>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

When listing the directives, list those for more specific URLs first. In practice this shouldn’t actually be required as the Alias directive should take precedence over WSGIScriptAlias, but good practice all the same.

Do note though that if using Apache 1.3, the Alias directive will only take precedence over WSGIScriptAlias if the mod_wsgi module is loaded prior to the mod_alias module. To ensure this, the LoadModule/AddModule directives are used.

Note that there is never a need to use SetHandler to reset the Apache content handler back to ‘None’ for URLs mapped to static files. That this is a requirement for mod_python is a short coming in mod_python, do not do the same thing for mod_wsgi.

Limiting Request Content

By default Apache does not limit the amount of data that may be pushed to the server via a HTTP request such as a POST. That this is the case means that malicious users could attempt to overload a server by attempting to upload excessively large amounts of data.

If a WSGI application is not designed properly and doesn’t limit this itself in some way, and attempts to load the whole request content into memory, it could cause an application to exhaust available memory.

If it is unknown if a WSGI application properly protects itself against such attempts to upload excessively large amounts of data, then the Apache LimitRequestBody directive can be used:

LimitRequestBody 1048576

The argument to the LimitRequestBody should be the maxumum number of bytes that should be allowed in the content of a request.

When this directive is used, mod_wsgi will perform the check prior to actually passing a request off to a WSGI application. When the limit is exceeded mod_wsgi will immediately return the HTTP 413 error response without even invoking the WSGI application to handle the request. Any request content will not be read as the client connection will then be closed.

Note that the HTTP 413 error response page will be that defined by Apache, or as specified by the Apache ErrorDocument directive for that error type.

Defining Application Groups

By default each WSGI application is placed into its own distinct application group. This means that each application will be given its own distinct Python sub interpreter to run code within. Although this means that applications will be isolated and cannot in general interfere with the Python code components of each other, each will load its own copy of all Python modules it requires into memory. If you have many applications and they use a lot of different Python modules this can result in large process sizes.

To avoid large process sizes, if you know that applications within a directory can safely coexist and run together within the same Python sub interpreter, you can specify that all applications within a certain context should be placed in the same application group. This is indicated by using the WSGIApplicationGroup directive:

<Directory /usr/local/wsgi/scripts>
WSGIApplicationGroup admin-scripts

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

The argument to the WSGIApplicationGroup directive can in general be any unique name of your choosing, although there are also a number of special values which you can use as well. For further information about these special values see the more detailed documentation on theWSGIApplicationGroup directive. Two of the special values worth highlighting are:

%{GLOBAL}

The application group name will be set to the empty string.

Any WSGI applications in the global application group will always be executed within the context of the first interpreter created by Python when it is initialised. Forcing a WSGI application to run within the first interpreter can be necessary when a third party C extension module for Python has used the simplified threading API for manipulation of the Python GIL and thus will not run correctly within any additional sub interpreters created by Python.

%{ENV:variable}

The application group name will be set to the value of the named environment variable. The environment variable is looked-up via the internal Apache notes and subprocess environment data structures and (if not found there) via getenv() from the Apache server process.

In an Apache configuration file, environment variables accessible using the 

<span class="pre">%{ENV}</span>

 variable reference can be setup by using directives such as SetEnv and RewriteRule.

For example, to group all WSGI scripts for a specific user when using mod_userdir within the same application group, the following could be used:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/~([^/]+)
RewriteRule . - [E=APPLICATION_GROUP:~%1]

<Directory /home/*/public_html/wsgi-scripts/>
Options ExecCGI
SetHandler wsgi-script
WSGIApplicationGroup %{ENV:APPLICATION_GROUP}
</Directory>

Defining Process Groups

By default all WSGI applications will run in what is called ‘embedded’ mode. That is, the applications are run within Python sub interpreters hosted within the Apache child processes. Although this results in the best performance possible, there are a few down sides.

First off, embedded mode is not recommended where you are not adept at tuning Apache. This is because the default MPM settings are never usually suitable for Python web applications, instead being biased towards static file serving and PHP applications. If you run embedded mode without tuning the MPM settings, you can experience problems with memory usage, due to default number of processes being too many, and can also experience load spikes, due to how Apache performs lazy creation of processes to meet demand.

Secondly, embedded mode would not be suitable for shared web hosting environments as all applications run as the same user and through various means could interfere with each other.

Running multiple Python applications within the same process, even if separated into distinct sub interpreters also presents other challenges and problems. These include problems with Python extension modules not being implemented correctly such that they work from a secondary sub interpreter, or when used from multiple sub interpreters at the same time.

Where multiple applications, potentially owned by different users, need to be run, ‘daemon’ mode of mod_wsgi should instead be used. Using daemon mode, each application can be delegated to its own dedicated daemon process running just the WSGI application, with the Apache child processes merely acting as proxies for delivering the requests to the application. Any static files associated with the application would still be served up by the Apache child processes to ensure best performance possible.

To denote that a daemon process should be created the WSGIDaemonProcess directive is used. The WSGIProcessGroup directive is then used to delegate specific WSGI applications to execute within that daemon process:

WSGIDaemonProcess www.site.com threads=15 maximum-requests=10000

Alias /favicon.ico /usr/local/wsgi/static/favicon.ico

AliasMatch /([^/]*\.css) /usr/local/wsgi/static/styles/$1

Alias /media/ /usr/local/wsgi/static/media/

<Directory /usr/local/wsgi/static>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi
WSGIProcessGroup www.site.com

<Directory /usr/local/wsgi/scripts>

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
</IfVersion>
<IfVersion >= 2.4>
    Require all granted
</IfVersion>
</Directory>

Where Apache has been started as the 

<span class="pre">root</span>

 user, the daemon processes can optionally be run as a user different to that which the Apache child processes would normally be run as. The number of daemon processes making up the process group and whether they are single or multithreaded can also be controlled.

A further option which should be considered is that which dictates the maximum number of requests that a daemon process should be allowed to accept before the daemon process is shutdown and restarted. This should be used where there are problems with increasing memory use due to problems with the application itself or a third party extension module.

As a general recommendation it would probably be a good idea to use the maximum requests option when running large installations of packages such as Trac and MoinMoin. Any large web site based on frameworks such as Django, TurboGears and Pylons or applications which use a database backend may also benefit.

If an application does not shutdown cleanly when the maximum number of requests has been reached, it will be killed off after the shutdown timeout has expired. If this occurs on a regular basis you should run with more than a single daemon process in the process group such that the other process can still accept requests while the first is being restarted.

If the maximum requests option is not specified, then the daemon process will never expire and will only be restarted if Apache is restarted or the user explicitly signals it to restart.

For further information about the options that can be supplied to the WSGIDaemonProcess directive see the more detailed documentation for WSGIDaemonProcess. A few of the options which can be supplied to the WSGIDaemonProcess directive worth highlighting are:

user=name | user=#uid

Defines the UNIX user _name_ or numeric user _uid_ of the user that the daemon processes should be run as. If this option is not supplied the daemon processes will be run as the same user that Apache would run child processes and as defined by the User directive.

Note that this option is ignored if Apache wasn’t started as the root user, in which case no matter what the settings, the daemon processes will be run as the user that Apache was started as.

group=name | group=#gid

Defines the UNIX group _name_ or numeric group _gid_ of the primary group that the daemon processes should be run as. If this option is not supplied the daemon processes will be run as the same group that Apache would run child processes and as defined by the Group directive.

Note that this option is ignored if Apache wasn’t started as the root user, in which case no matter what the settings, the daemon processes will be run as the group that Apache was started as.

processes=num

Defines the number of daemon processes that should be started in this process group. If not defined then only one process will be run in this process group.

Note that if this option is defined as ‘processes=1’, then the WSGI environment attribute called ‘wsgi.multiprocess’ will be set to be True whereas not providing the option at all will result in the attribute being set to be False. This distinction is to allow for where some form of mapping mechanism might be used to distribute requests across multiple process groups and thus in effect it is still a multiprocess application. If you need to ensure that ‘wsgi.multiprocess’ is False so that interactive debuggers will work, simply do not specify the ‘processes’ option and allow the default single daemon process to be created in the process group.

threads=num

Defines the number of threads to be created to handle requests in each daemon process within the process group.

If this option is not defined then the default will be to create 15 threads in each daemon process within the process group.

maximum-requests=nnn

Defines a limit on the number of requests a daemon process should process before it is shutdown and restarted. Setting this to a non zero value has the benefit of limiting the amount of memory that a process can consume by (accidental) memory leakage.

If this option is not defined, or is defined to be 0, then the daemon process will be persistent and will continue to service requests until Apache itself is restarted or shutdown.

Note that the name of the daemon process group must be unique for the whole server. That is, it is not possible to use the same daemon process group name in different virtual hosts.

If the WSGIDaemonProcess directive is specified outside of all virtual host containers, any WSGI application can be delegated to be run within that daemon process group. If the WSGIDaemonProcess directive is specified within a virtual host container, only WSGI applications associated with virtual hosts with the same server name as that virtual host can be delegated to that set of daemon processes.

When WSGIDaemonProcess is associated with a virtual host, the error log associated with that virtual host will be used for all Apache error log output from mod_wsgi rather than it appear in the main Apache error log.

For example, if a server is hosting two virtual hosts and it is desired that the WSGI applications related to each virtual host run in distinct processes of their own and as a user which is the owner of that virtual host, the following could be used:

<VirtualHost *:80>
ServerName www.site1.com
CustomLog logs/www.site1.com-access_log common
ErrorLog logs/ww.site1.com-error_log

WSGIDaemonProcess www.site1.com user=joe group=joe processes=2 threads=25
WSGIProcessGroup www.site1.com

...
</VirtualHost>

<VirtualHost *:80>
ServerName www.site2.com
CustomLog logs/www.site2.com-access_log common
ErrorLog logs/www.site2.com-error_log

WSGIDaemonProcess www.site2.com user=bob group=bob processes=2 threads=25
WSGIProcessGroup www.site2.com

...
</VirtualHost>

When using the WSGIProcessGroup directive, the argument to the directive can be either one of two special expanding variables or the actual name of a group of daemon processes setup using the WSGIDaemonProcess directive. The meaning of the special variables are:

%{GLOBAL}

The process group name will be set to the empty string. Any WSGI applications in the global process group will always be executed within the context of the standard Apache child processes. Such WSGI applications will incur the least runtime overhead, however, they will share the same process space with other Apache modules such as PHP, as well as the process being used to serve up static file content. Running WSGI applications within the standard Apache child processes will also mean the application will run as the user that Apache would normally run as.

%{ENV:variable}

The process group name will be set to the value of the named environment variable. The environment variable is looked-up via the internal Apache notes and subprocess environment data structures and (if not found there) via getenv() from the Apache server process. The result must identify a named process group setup using the WSGIDaemonProcess directive.

In an Apache configuration file, environment variables accessible using the %{ENV} variable reference can be setup by using directives such as SetEnv and RewriteRule.

For example, to select which process group a specific WSGI application should execute within based on entries in a database file, the following could be used:

RewriteEngine On
RewriteMap wsgiprocmap dbm:/etc/httpd/wsgiprocmap.dbm
RewriteRule . - [E=PROCESS_GROUP:${wsgiprocmap:%{REQUEST_URI}}]

WSGIProcessGroup %{ENV:PROCESS_GROUP}

Note that the WSGIDaemonProcess directive and corresponding features are not available on Windows or when running Apache 1.3.

Ubuntu18.04下完美切换Python版本

ubuntu18.04版本,python版本python2.7,python3.5,python3.6

因为安装一些库会安装到python3.6上,而默认使用的是python2.7,使用python3,默认会使用python3.5,无法调用安装包。

解决方法:

一,使用python xx.py运行程序时,加上版本号。比如python3.6 xx.py

二,1,要以root身份操作


yz@yz-<span class="hljs-symbol">pc:</span>~$ sudo su

2,确认本机下的python默认版本。调出终端,输入python即可查看默认的版本:

  1. root@yz-pc:/home/yz# python
  2. Python 3.6.5 (default, Apr 1 2018, 05:46:30)
  3. [GCC 7.3.0] on linux
  4. Type “help”, “copyright”, “credits” or “license” for more information.
  5. >>> exit()
  6. root@yz-pc:/home/yz# python2.7
  7. Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
  8. [GCC 7.3.0] on linux2
  9. Type “help”, “copyright”, “credits” or “license” for more information.
  10. >>> exit()
  11. root@yz-pc:/home/yz# python3
  12. Python 3.6.5 (default, Apr 1 2018, 05:46:30)
  13. [GCC 7.3.0] on linux
  14. Type “help”, “copyright”, “credits” or “license” for more information.
  15. >>> exit()
  16. root@yz-pc:/home/yz# python3.5

3,如何切换这两个版本以及切换默认的python版本:

我们可以使用 update-alternatives 来为整个系统更改Python 版本。以 root 身份登录,首先罗列出所有可用的python 替代版本信息:

  1. #update-alternatives –list python
  2. update-alternatives: error: no alternatives for python

如果出现以上所示的错误信息,则表示 Python 的替代版本尚未被update-alternatives 命令识别。想解决这个问题,我们需要更新一下替代列表,将python2.7 和 python3.6放入其中。

  1. # update-alternatives –install /usr/bin/python python /usr/bin/python2.7 1
  2. update-alternatives: using /usr/bin/python2.7 to provide /usr/bin/python (python) in auto mode
  3. # update-alternatives –install /usr/bin/python python /usr/bin/python3.5 2
  4. update-alternatives: using /usr/bin/python3.4 to provide /usr/bin/python (python) in auto mode

–install 选项使用了多个参数用于创建符号链接。最后一个参数指定了此选项的优先级,如果我们没有手动来设置替代选项,那么具有最高优先 级的选项就会被选中。这个例子中,我们为/usr/bin/python3.4 设置的优先级为2,所以update-alternatives 命 令会自动将它设置为默认 Python 版本。

  1. # python –version
  2. Python 3.5.2

接下来,我们再次列出可用的 Python 替代版本。

  1. # update-alternatives –list python
  2. /usr/bin/python2.7
  3. /usr/bin/python3.5

现在开始,我们就可以使用下方的命令随时在列出的 Python 替代版本中任意切换了。

(这一步是最关键的)


<span class="hljs-comment"># update-alternatives --config python</span>

下面就简单了,会提示你输入序号,你想用哪个版本为默认,就输入序号就可以了!

ubuntu1

教你炒股票14:喝茅台的高潮程序!

前面说了很多理论上的东西,现在用一个实际的股票来说明一下具体的用法。就用茅台吧,边喝茅台边上课。这里先假设所有看的人都能找到茅台上市以来的周线和日线图。前面说过两条均线间“吻”的三种方式,其中的湿吻是最明显的缠绕例子,而飞吻和唇吻是缠绕的特殊例子,在均线操作系统中所指的缠绕,包括这三种吻。而从实际的比例看,湿吻出现的几率是最大的,但在长期均线系统中,例如周线、月线等,唇吻的例子比例也很大。先复习一下相关定义:

飞吻:短期均线略略走平后继续按原来趋势进行下去。
唇吻:短期均线靠近长期均线但不跌破或升破,然后按原来趋势继续下去。
湿吻:短期均线跌破或升破长期均线甚至出现反复缠绕,如胶似漆。
女上位:短期均线在长期均线之上。
男上位:短期均线在长期均线之下。
第一类买点:用比较形象的语言描述就是由男上位最后一吻后出现的背驰式下跌构成。
第二类买点:女上位第一吻后出现的下跌构成。

现在,先打开茅台的周线图,在茅台快6年的周线图上,用5周与10周均线构成的买卖系统,只有第一类和第二类买点各一个,可见,在周线图上,按均线系统构成的买点并不常见,一旦出现必须珍惜。仔细分析:2002419日那周,茅台进入男上位,其后在200279日那周进入男上位的第一吻,前面已经说过,这第一吻后的下跌一般不会构成买点,必须是至少第二吻以后。其第二吻出现在2003214日那周,是典型的湿温,其后在下跌并没构成背驰,不符合第一类买入点的原则。然后在2003627日那周构成第三吻,是一个不太强烈的湿吻,其后的下跌就出现了明显的背驰走势,在MACD图上,绿柱子比上一次的明显缩短,而低位却低于上次绿柱子出现时的低位。如何判断背驰走势结束,最简单的就是当绿柱子缩短,而股价继续创新低,这次,明显地发生在2003926日这一周,意味着底部出现,第一类买点构造完成,可以大举介入了。

 14-3

第一类买点出现后,茅台也正常地改变体位,进入女上位,一直到200464日那周出现女上位后的第一吻,其后的下跌构成周线上的第二类买点。这里有一个很重要的技巧,就是第二类买点如何精确地把握,由于在周线女上位后第一吻的调整不构成明显的下跌走势,因此对于第一类买点的背弛走法就无法出现,这时候就要降低K线级别,从日线图上寻找最佳买点,这里给出一个缠中说禅买点定律:大级别的第二类买点由次一级别相应走势的第一类买点构成(该定律是有专利的,发明权一定要明确,这一点必须明确,否则以后本ID不会再说任何定律了,该定律一定没有任何人发现过,其他本ID已发现的定律也一样,哪天本ID心情好再说几个,但前提是不能让本ID发现有盗版的,各位也应该和本ID一起监督)。例如,周线上的第二类买点由日线上相应走势的第一类买点构成。有了这个缠中说禅买点定律,所有的买点都可以归结到第一类买点。

对于茅台,200464日那周出现女上位后第一吻,对应在日线图上是明显的男上位走势,该走势其中出现三次吻,分别在2004429日、518日、61日,都是典型的湿吻,但前两次其后的下跌都没有出现背驰,只有第三次,出现明显的背驰性走势,618日创下低点后,MACD的绿柱子明显比前面的要缩短,这就构成了日线上的第一类买点,而这个买点,在周线上就是第二类买点。注意,后面由于除权,价位上似乎比这个要低了,其实并没有。

站在周线角度,茅台的买点就这两个了,而其后的卖点至今没出现,如果当时根据这两个买点介入的,目前应该继续持有,直到卖点出现。但是,这是一种针对特别大资金的玩法法,例如50亿以上,对于资金量一般的,例如10亿以下的,有一种增加资金流动性的玩法,就是充分利用日线的卖点回避大的调整,虽然这种调整站在周线的角度不一定要参与。缠中说禅短差程序就是:大级别买点介入的,在次级别第一类卖点出现时,可以先减仓,其后在次级别第一类买点出现时回补。对于周线买点介入的,就应该利用日线的第一类卖点减仓,其后在第一类买点回补。对于茅台,分析如下:

14-2

14-1

      在周线2003926日这一周根据第一类买点介入的,其后的女上位出现九次吻,前八次都没构成背驰走势,而第九次出现在2004326日,其后的上涨出现明显背驰,48日的高位对应的MACD红柱子并没有相应创出新高,这就构成日线上的第一类卖点。其后的第一类买点出现在618日,然后的第一类卖点出现在1027日,然后第一类买点出现在1222日,下一个第一类卖点出现在2005426日,接着的第一类买点出现在20051213日,下面的第一类卖点至今没出现,也就是说,即使是站在日线的角度,20051213日介入的茅台,根本就没有出现卖点,唯一正确的就是坚决持有。当然,如果资金量小,不是按周线的,第一类、第二类买点都是最多按日线的,就可以相应在30分钟等更小的级别内找到第一类卖点而弄出短差来,那就太细了,各位自己研究去。

  要把握好这个均线构成的买卖系统,必须深刻理解缠中说缠买点定律:大级别的第二类买点由次一级别相应走势的第一类买点构成。如果资金量不特别巨大,就要熟练缠中说禅短差程序:大级别买点介入的,在次级别第一类卖点出现时,可以先减仓,其后在次级别第一类买点出现时回补。这样才能提高资金的利用率。注意,该定律和程序都要注意版权,任何人都可以用,也不收任何版权费,但这个版权必须要明确,否则本ID心情不好,就没兴趣再说任何定律、程序了。严惩所有企图盗版去招摇撞骗的人。各位要多看图,根据相应的资金量以及性格去定自己的操作级别,然后具体是熟练,否则就是纸上谈兵,毫无意义了。

回复:

缠中说禅 2006-12-05 11:53:53

ID对大盘的建议继续有效,引用如下:

该结论继续有效

缠中说禅 2006-11-29 15:14:38

从大盘健康的角度说,本ID给大盘的建议是:先深成指突破6103点的历史高位,然后上海跟上,突破以后再调整,这样更健康。不知道大盘有没有兴趣听本ID的意见了

缠中说禅 2006-12-05 12:04:22

注意,本ID从来没有参加过其他任何圈子,任何以本ID名义参加的圈子都与本ID无关,本ID和发现在新浪中有一个博客和本ID名字完全一样的,但其地址不同,所以各位请注意,不要混淆了。

ID只有自己刚建立的一个圈子,这个圈子欢迎所有人把自己的文章贴在上面互相交流。除此之外,一切与本ID无关,特此声明。

缠中说禅 2006-12-05 12:06:44

[匿名] 外科医生 2006-12-05 11:58:23

小妹,这次接下来的调整怎么判断呢?

===========

比上次厉害但中线问题不大没涨的还会借机启动二线股后是三线股把握该节奏

缠中说禅 2006-12-05 12:13:42

小明 2006-12-05 12:10:46

楼主,600183也算二线蓝筹,为何到现在还没怎么动?

马上都要轮到三线了,它不是要歇菜?

==========

典型的庄股等庄家有心情了自然涨了

缠中说禅 2006-12-05 12:19:26

[匿名] 外科医生 2006-12-05 12:10:50

我的600639今天又涨停了,看了一下日线好像背迟了,红烛缩小了对吗?

===========

没有但中线已经进入成交密集区域再上行后短线出现震荡洗盘很正常

缠中说禅 2006-12-05 12:23:04

小明 2006-12-05 12:17:51

好好研究本帖子真明白了至少比市场上95%的人要厉害了

先仔细研究不研究怎么会正在明白和应用不要把自己的思想限制在一个范围只是牛市第一期是成分股的天下牛市第二期就要变了不患而患<<>论语>

缠中说禅 2006-12-05 12:25:25

[匿名] 妄语 2006-12-05 12:18:29

请教:“而对于上一章所说的第二个买点,一旦该缠绕中出现跌破前面男上位的最低位,就意味着买入程序出现问题,必须在任何一个反弹中把股票出清,在这种情况下,不排除后面出现上涨,”60051987号的破位属于这种情况吗?

=========

那是买点不要搞错了即使站在日线角度前期的低位在526日的37元多怎么会跌破了不要把两种情况搞糊涂了

缠中说禅 2006-12-05 12:48:32

[匿名] 你的粉丝 2006-12-05 12:36:59

请教000530这几个交易日每天就涨一两分钱,怎么理解?

============

不要关心一些不太重要的信息要找到自己的坚固港湾用上面的方法从周线图分析该股票就知道这股票中线正干什么了

缠中说禅 2006-12-05 12:52:01

[匿名] 想飞的猪 2006-12-05 12:41:48

无意中闯入缠禅的地盘,像是进入了一座思想的圣殿,学习中。。。

感谢缠禅无私的分享、悉心的指点。

有个问题想请教,调整是迟早的事,面对即将的大盘调整,如何处理手中已有涨幅、但中期仍看好的二线蓝筹股呢?比如600787,它的卖点体位还不明显,是先行撤出,还是静待中线心理价位再卖?

很多能搞的股票,从图形上,结合你的理论,似乎卖点都不清晰,在大盘如此疯狂的拉抬下,在600028等几只指标股貌似做头的图形下,如何处理已有获利的中线?

谢谢缠禅先!

============

方法都告诉你了要举一反三:

缠中说禅短差程序:大级别买点介入的,在次级别第一类卖点出现时,可以先减仓,其后在次级别第一类买点出现时回补。

缠中说禅 2006-12-05 12:53:55

[匿名] CCTV 2006-12-05 12:52:59

LZ,至少我是支持你的别人怎么我管不着

=============

谢谢不过本ID允许任何意见存在只要新浪不删就可以

小明 2006-12-05 12:54:41

心茫 各位博友注意!

俗话说:“真传一句话,假传万卷书”!凡是难懂的理论,不懂就不懂吧,不必浪费时间琢摸!果断掉头走开,反而会把损失降到最低点。

“高抛低吸”真传就这么简单!因为所有错综复杂的组合及变化都体现在价格上!

===============

“高抛低吸”,说的轻巧,谁不知道高抛低吸!我做梦都想高抛低吸!但是落实到行动上,你怎么就知道你进入的就是低点? 如果要止蚀,越低越买那不套死?又怎么知道你卖出的就是高点?很多大牛就骑了一小段就下来的惨痛例子还少?

我们来这里正是为解决这个问题而来的!

相信不久的将来,这里将变成富人俱乐部。

缠中说禅 2006-12-05 12:54:49

开盘了先下再见

缠中说禅 2006-12-05 13:46:42

有事要先走下午来不了了晚上再上来以下提示继续有效:

缠中说禅 2006-12-01 15:02:23

技术上,今天深圳成指留下的缺口十分重要,如果很快回补,则技术上发出不好的信号。

下周一依然有震荡的需要,但各股行情依然继续。由于11月是巨阳,12月上冲后出现大幅震荡不可避免,这必须要清醒。

缠中说禅 2006-12-05 21:56:43

[匿名] 你的粉丝 2006-12-05 12:56:56

000530周线飞吻后上行,刚突破250线,继续持股。

不知道我分析得对吗?老师。

===========

有继续持有而周线的第一二类买点早过该股走势很标准可以分析学习

缠中说禅 2006-12-05 21:58:17

[匿名] 妄语 2006-12-05 13:15:51

试呼有些略懂了,还在琢磨中。。。缠女能不能找个此方法失败或必须止损的票来和600519对应比较,以便能更深刻理解。先谢了。

=========

在周线上失败的例子还真不好找有找到的请举出来

缠中说禅 2006-12-05 22:12:54

[匿名] 在路上 2006-12-05 13:52:21

请教缠姐:关于茅台1222日买点至2005426的卖点买点好理解卖点有点疑问为什么不是413,那天它的MACD明显背驰了啊

我理解是其后才出现第一次湿吻,(对这一次的买卖),但其后426MACD又明显放大了按当时来看应该不算背驰啊请指教

=============

ID用的MACD周期比普通的要长一倍按普通的指标,413日的背驰构成的是MACD双头走势一般到零轴后都有双次拉回这次才是构成最终的背弛有关背弛的课上会详细说

缠中说禅 2006-12-05 22:18:03

[匿名] 笨笨猪 2006-12-05 14:55:34

我的分析:000530经过长期的纠缠上涨,相信庄家已经收足筹码,这两日放量上涨之后即将回调。短线高手可以介入,中长线时机已经错过。

==============

 

可以但最好习惯用第一\二类买点来分析周线就不说了自己去分析日线上最近一次的第一类买点在926第二类买点在1023这是根据日线图介入的最好两个位置至于后面的介入要根据30分钟图了

缠中说禅 2006-12-05 22:19:50

[匿名] 小明 2006-12-05 21:16:43

早上入了000623 追高了,

后市情况如何?还能不能搞?

=======

一定要找到自己坚固的港湾如果喜欢弄短线可以用5分钟图甚至1分钟找第一\二类买点根本没必要去追高

缠中说禅 2006-12-05 22:23:28

各位好好去研究一下真明白了终生受益一定要看图研究清楚不明白的本ID都尽量解释明白的

大盘如期进入震荡,5日线是短线关键但个股问题不大特别没动的二\三线股

先下了再见

教你炒股票13:不带套的操作不是好操作!

不带套的男人是否好男人,这个问题暂且不说,不带套的操作一定不是好操作票,特别对于资金量大的!带套有两种,一种是主动、一种是被动。何谓被动带套?就是介入时根本不知道为何介入,在一种盲目的状态下被套了,然后还有一种很错误的理论,认为亏损多少就要止蚀,按这种方法来操作,最终都不可能大成功的。几乎所有的投资者,都是这种被动带套的,这种人,都是被套所套。

其实,从来不存在真正的止蚀问题,只存在股票是否依然在能搞的范围内的问题,只有这种意义下才存在止蚀:一只股票的走势从能搞变成不能搞。请注意,站在盈亏的,这时并不意味着操作是失败了,可能已经大大赢利了,唯一退出的原因只是股票的走势已经不能搞了。投资市场中一个最坏的毛病就是根据盈亏进出,而盈亏不是先验的,是根据当下的走势当下决定的,是被动的,根据盈亏进出,就是根据被动的因数进出,这不是被动带套是什么?

何谓主动带套?这里有两层意思。其一,介入不可能一下子完成,特别对于大资金来说,如果不采取主动带套的方法,怎么可能买到足够的货?那种号称从来不带套的,肯定从来没操作过大资金。但更重要的是,任何的介入,都有一个主动的防护加入其中,这个防护就是从一旦变为不能搞,就立刻从买入程序中此退出,这个防护的启动是和任何盈亏无关的,只和当下的走势有关。

例如,在上一章所说的买入程序里,对于第一个买点,一旦上涨时依然出现男上位的缠绕,那么一定要退出,为什么?因为第一个买点买入的基础在于男上位最后一个缠绕后出现背驰,而现在又出现男上位的缠绕,意味着前面引导买入程序启动的缠绕并不是最后一个缠绕,也就是程序判断上出现问题,因此必须退出。一般情况下,这种退出一定是赢利的,但这并不能成为不退出的理由。甚至不排除这种情况,就是退出后,缠绕经过以时间换空间的折腾慢慢变成女上位,最后还大幅上涨了(这种情况即使出现,也可以根据第二个买点的原则重新介入,所以真正的机会并不会丢失),但即使这样,也绝对不能因为这种可能的情况有侥幸心理。因为还有更大的可能是缠绕后出现加速下跌。对于走势,可能是无位次的,而实现是有位次的,而任何的操作,只能建立在有位次的基础上,这对于熟悉本ID所解《论语》的人应该能理解。半部《论语》治天下,就别说股市了,要股市上脱胎换骨,多看本ID说的《论语》,那是源泉。

   而对于上一章所说的第二个买点,一旦该缠绕中出现跌破前面男上位的最低位,就意味着买入程序出现问题,必须在任何一个反弹中把股票出清,在这种情况下,不排除后面出现上涨,但理由如上,任何操作,没有百分百准确的,一旦出现特殊情况,一定要先退出来,这是在投资生涯中能长期存活的最重要一点。当然,有经验的人,即使退出,也会按部就班,很有秩序,这和打仗是一个道理,一发现战机不对,就要撤,不能硬抗,否则不给灭了才怪了。

   投资是一个长期的事业,别抱着赌博的心态企图一次成功,只要有这种心态,最终的结局一定悲惨,这已经被无数事例所验证。为什么要研究符合自己的买卖程序?就是因为这是市场风浪中唯一安全的港湾,港湾有时候也会有台风,但不能因为有时候有台风就不要港湾了。还有一点,就是买入程序的成功率和市场的强度有关,在强的市场里,买入程序的成功率基本都在90%以上,但在弱的市场里,这成功率就要低多了。

任何根据均线等技术系统构成的买卖程序,都只是一个综合判断的一个子判断,并不是说这一招就可以了。至少有一点是任何技术的买卖程序不能解决的,就是相同程序选出来的股票,为什么有些涨得多、有些涨的少,能不能就此而选出最有力度的,这在实际的操作中是很有意义的问题。用一个庸俗的比喻,技术系统是“海选”,而其后需要的是“复赛”、“PK”,这才能选出真正可以介入的股票。关于这个问题,在后面会逐步展开。

回复:

缠中说禅 2006-12-04 12:15:49

ID对大盘的建议继续有效,引用如下:

该结论继续有效

缠中说禅 2006-11-29 15:14:38

从大盘健康的角度说,本ID给大盘的建议是:先深成指突破6103点的历史高位,然后上海跟上,突破以后再调整,这样更健康。不知道大盘有没有兴趣听本ID的意见了

缠中说禅 2006-12-04 12:17:22

很高兴上海今天能接受本ID下面的警告终于不捣乱了希望继续发扬

缠中说禅 2006-12-01 12:16:49

现在大盘最大的风险是上海人比较小气,因为深圳先突破历史新高几乎是不可改变的了。上海有可能故意捣乱,让大家都突破不了。这种事情听起来像天方夜谈,但历史上出现过不止一次了。但历史却一次次地证明,只要是大牛市,深圳就是比上海牛,这也是判断行情的一个很重要的经验。当深圳比上海弱时,是大行情的机会很小的。现在看到深圳比上海强,即使是上海人,也应该为此高兴。

缠中说禅 2006-12-04 12:18:41

公告

ID建立了一个圈子,但不是为了本ID,只是方便来这里的人互相交流,把自己好的文章放到一个地方方便借鉴。点击本ID博客首页左侧的“我的圈子”就能找到。没有设置任何门槛,任何人都可以加入,然后就可以把自己的文章放到上面了,有兴趣的可以看一下。

只要是新浪允许的文章都可以放上去,本ID不会管也没时间管。

缠中说禅 2006-12-04 12:25:41

[匿名] 糊涂蛋 2006-12-04 12:24:36

前段时间看见“大牛不用套”,现在“不带套的操作不是好操作”,数女是提醒防范风险吗?

============

这是一般性操作问题,和大盘走势无关。

缠中说禅 2006-12-04 12:37:10

本月大盘走势,以下话依然有效:

2006-12-01 15:02:23

由于11月是巨阳,12月上冲后出现大幅震荡不可避免,这必须要清醒。

缠中说禅 2006-12-04 12:41:04

[匿名] 糊涂蛋 2006-12-04 12:33:58

因可能要出去一段时间,我想把满仓的600653000822换成000932,值吗?

==========

要养成完成整个操作的习惯,如果持有的股票没有出现卖出信号,就要一路持有,没有人能保证换回来的一定是金子,即使事后真是金子,那也是事后,但却养成了一个坏习惯。

投资市场,习惯是最重要的。一个坏习惯就足以致命。

缠中说禅 2006-12-04 12:43:34

离开市场一定要有人跟进,不能把股票抛一边没人管,这不是一个市场参与者应该有的态度,现在网络发达,即使外出,关照一下股票还是不难的。

缠中说禅 2006-12-04 12:46:03

[匿名] 醉酒青牛 2006-12-04 12:43:08

我老牛现在搞搞时都在想女上位和男上位的问题数女妹妹还是多写点我搞了几年都没入门啊希望你的文章让我开悟啊

============

学技术分析,关键是多看图,还有一点必须注意,就是不能唯技术分析,必须注意其缺点。

缠中说禅 2006-12-04 12:50:01

[匿名] nn 2006-12-04 12:45:13

整篇文章都很有道理只是想问一下假如撤出时很难做到不亏损那么还能等反弹吗如真那样亏损不就更大吗当然这种情况多半出现在熊市可是牛市基本不需要止损对吗因为介入时基本都把它作为可搞之列而介入的俺的理解对吗

============

其实,熟悉走势的人根本不需要等到真跌破低点了才发现问题,一般来说,一半的位置是不会跌破的,一旦跌破,就是会出问题。至于跌破低点,一般都会有反抽的,这是最后的走人机会。再不走,只能杀跌走了。

缠中说禅 2006-12-04 12:51:18

[匿名] 淡定 2006-12-04 12:49:23

楼主000001600050两只股票如何?多谢

===========

女上位,该怎么操作,上面已经说的够多了,就是耐心持有等待第一个卖点的出现。

缠中说禅 2006-12-04 12:56:06

[匿名] 外科医生 2006-12-04 12:51:09

现在有人在说3000点了,你觉得离大盘突然死亡还有多远

=============

ID一年半前私下就说过,这行情N年以后最终可以走到5000点甚至一万点,3000点很离谱吗?

关键不是点位,而是如何利用大的调整去增加资金利用率。别关心点位,特别对于散户来说,任何一个级别大点的调整都应该避开,没必要参与。行情走到10000点,对于散户来说,完全可以分解成很多段来操作,所以对最终点位的预测其实意义不大。

缠中说禅 2006-12-04 12:58:07

[匿名] 多多 2006-12-04 12:51:10

请教楼主6002102。40买入可否继续持有谢谢

===========

学了这么多,你应该问自己,目前在你根据自己情况设定的标准下,他还能搞吗?能就持有,不能就不持有,就这么简单。没有先验标准是四海皆准的。

缠中说禅 2006-12-04 12:59:43

[匿名] 数女粉丝 2006-12-04 12:53:22

请问600607可以搞吗?

=========

没涨的都要补涨,这种问题没什么意义,关键是你自己的实际情况。最好用上面教的自己慢慢学会判断。

缠中说禅 2006-12-04 13:00:02

开盘了,先下。再见。

缠中说禅 2006-12-04 13:24:23

短线判断大盘调整的一个最简单方法就是深沪指数的背离一旦出现调整或至少是震荡将很快发生方法说了具体就自己马上实践一下不能什么都说好了这样永远无法提高

缠中说禅 2006-12-04 15:02:36

[匿名] 小明 2006-12-04 14:53:36

[匿名] 缠禅 2006-12-04 13:51:34

数女,你说的均线缠绕比较难理解!我怎么看av觉得510日线都是缠来缠去,总是互相变换体位!找不到转折点啊!

======================================

没有选对股票,看600519就很典型。

===========

转折点不是看均线而是指当出现符合要求的缠绕时每次下跌都是好的买货机会如果希望买点更加精确可以中短套用这样基本就能买到最精确的底部这个问题上次详细说

布置一个作业各位好好看看茅台的月线周线日线图然后分别将符合要求的买点找出来

缠中说禅 2006-12-04 15:12:37

[匿名] 2006-12-04 13:59:22

前段时间请教的000100(TCL),果然如楼主说的正在磨年线现已突破年线我也跟进补仓现在成本4。3,不知能否解套或需要再次补仓

==============

以后补仓就坚决一点别分着补一次性就把成本将到某个标准。4。3在明年是有机会达到的但如果是3。3机会就大多了很有可能明年上半年就见到

有一种方法就是也不再补仓了在下次中线上涨的高位把这次补仓的出掉然后等其后的中线调整回试年线在补回而原来套牢的一直不动这样估计你的成本能降到4元以下明年解套的机会就很大了

当然如果你的短线技术还可以就利用每次调整把回补的出一部分下来再回补这样反复几次很快就能解套了当然有一个原则原来套牢的不要动这用补仓的仓位来动这样既不增加仓位也不占用更多的资金其他钱可以关注另外的

缠中说禅 2006-12-04 15:17:21

[匿名] 木头 2006-12-04 15:06:16

数学妹妹,山东高速这股怎么样,能买吗?

谢谢你啊!

==============

牛市里随便什么时候买按赌博的几率算赢面也是很大的但这不是长久之计根据这几次课你应该知道符合要求的买点早过了究竟怎样好好自己分析一下这才是你自己的东西

缠中说禅 2006-12-04 15:21:04

[匿名] YY 2006-12-04 15:18:07

楼主,你这样精细的教我们,是不是想把我们也培养成你这样的高手啊?:)

==========

ID只能教最基本的技术心态没法教要学就要多学本ID说的<<>论语>然后反复在实际中修炼那才有提高的可能

缠中说禅 2006-12-04 15:23:17

[匿名] 瞎鼓捣

600058即是本人根据此程序选择的面首,请博主点评,谢谢。

==================

这选对了在周线上该股1117日那周是典型的第二类买点那时候介入就是最好的时机

缠中说禅 2006-12-04 15:27:58

[匿名] 中间体 2006-12-04 15:24:01

按缠姐的方发资金利用率是不是底虽然安全因为底部的个股上涨开始会很慢有时可能进一步缠绕是不是那种刚突破的个股比较好呢像今天的600832。 这样的话买入法就变了

============

想资金利用率高很简单把操作的图形改为分钟线等自然就高了但这对大资金无效ID所说是面对所有情况的而各人根据自己的资金量来选择相应的操作图形周期

 

缠中说禅 2006-12-04 15:35:32

今天下午走势前面的判断依然有效只要两市不互相拆台ID如下建议将如期很快实现所以现在只要看好两市是否背离就可以一旦背离就要特别小心了

缠中说禅 2006-11-29 15:14:38

从大盘健康的角度说,本ID给大盘的建议是:先深成指突破6103点的历史高位,然后上海跟上,突破以后再调整,这样更健康。不知道大盘有没有兴趣听本ID的意见了

缠中说禅 2006-12-04 15:37:38

[匿名] 小明 2006-12-04 15:34:46

由于本人的资金很小,平均每个股票待在手里不过2天,所以到现在虽然是牛了这么久,竟然还亏钱。

我准备按照缠mm所说,适当的看分钟线。请问,分钟线看多少分钟的适宜?30分钟是不是最好的?

===========

自己好好选择多模拟多看历史走势用小资金学会了以后就好办了如果是超短线,5分钟就足够了

缠中说禅 2006-12-04 15:40:10

学技术各位一定要多看图把所有疑问都要搞清楚不清楚就提在这里ID在后面的课程里会继续说的一定要搞明白不明白也要搞到明白为止

有问题就提在这里ID先下了再见

缠中说禅 2006-12-04 22:53:23

[匿名] 戈石 2006-12-04 19:53:18

尊敬的楼主:

不患,即本,不可描述的,绝对的,绝对真理,无位次的;患,即存在,可描述的,相对的,相对真理,有位次的。正因为绝对真理得无法描述,才有了参差不齐的各种相对真理来描述绝对真理,不要以为自己可以掌握绝对真理,绝对真理是不可求的,你能掌握的只是不同位次的相对真理。

这样理解对吗?

=============

当你把”不患“当绝对时,就又陷入某种陷阱里,就是一个先验概念构成的思维陷阱。

緾终禅:2009-03-23 00:04:45

可惜呀,安全与风险没有放在首位。您用生命给我们调皮响警钟。